WIKI TKJ

Mikrotik : Praktikum Uji Firewall RAW dan Diagnosa Connection Tracking

Firewall RAW sudah dipasang, connection tracking sudah diatur, tapi masalah di lapangan tetap muncul. Yang paling menyiksa: gejalanya mirip semua — koneksi mati, tapi tidak jelas di lapis mana paket itu berhenti.

Artikel ini adalah lab pembuktian. Kita sengaja merusak sembilan hal secara terkontrol, lalu menunjuk dengan tepat lapis mana yang membunuh paket — pakai angka, bukan perasaan.

Ini pendamping praktik dari Mikrotik : Firewall RAW dan Connection Tracking Lanjutan. Kalau belum paham urutan RAW sebelum conntrack, baca dulu artikel itu.

🎯 Tujuan

Setelah menyelesaikan lab ini, kamu bisa:

  • Membedakan bukti "paket dibuang RAW", "paket tidak pernah sampai", dan "conntrack penuh".
  • Membaca counter RAW, filter, NAT, dan tabel koneksi sebagai satu rangkaian bukti.
  • Membuktikan sendiri kenapa notrack mematikan NAT dan batas koneksi.
  • Menghitung anggaran entri conntrack untuk jumlah perangkat di jaringanmu.
  • Menemukan kenapa dst-limit dan connection-limit bisa menyumbat pengguna yang sah.
  • Menyiapkan jalan pulang sebelum mengunci diri sendiri dari router.

Perkiraan waktu: 60–90 menit. Alat: 1 router MikroTik (boleh CHR/VM), 1 laptop klien, 1 PC sebagai server uji, dan kabel.

📍 Konteks nyata

Bayangkan gedung dengan dua pos pemeriksaan. Pos pertama di pintu masuk: petugas memeriksa plat nomor dan langsung memulangkan yang mencurigakan. Pos kedua di dalam: buku tamu.

Kalau seorang pengunjung dipulangkan di pos pertama, namanya tidak akan pernah ada di buku tamu. Jadi "nama tidak ada di buku tamu" bukan bukti dia tidak pernah datang.

Di RouterOS, RAW adalah pos pertama dan conntrack adalah buku tamu. Banyak admin membaca "tidak ada entri koneksi" lalu langsung menyimpulkan "berarti diblokir RAW". Padahal bisa juga paketnya tidak pernah sampai, atau sengaja dilewatkan lewat notrack.

🔥 Kasus nyata: Sebuah SMK punya dua ruang lab. Setelah router sempat hang karena dibanjiri SYN ke port 8291, operator menambah beberapa rule RAW. Router jadi ringan, tapi login aplikasi CBT di ruang 2 mulai menggantung.

Operator melihat /ip firewall connection tracking print menunjukkan 88.000 entri, menyimpulkan conntrack penuh, lalu menaikkan timeout. Hasilnya makin parah. Ping ke gateway 1 ms, kecepatan unduh normal, hanya login aplikasi yang macet.

Penyebab sebenarnya: rule dst-limit=20,20,dst-address/1m untuk port 443 ke server CBT. Mode dst-address membuat satu ember dipakai bersama semua siswa. Empat puluh siswa berbagi 20 paket per detik.

Perbaikannya satu kata: mode diganti src-address. Total kerugian dua jam pelajaran, 40 siswa tertunda, dan tiga guru sempat menyalahkan ISP.

🧠 Konsep singkat

Satu paket bisa mati di lima tempat berbeda. Setiap tempat punya alat bukti sendiri. Urutkan pemeriksaan dari bawah ke atas.

Lapis Perintah bukti Kalau angkanya naik
Interface /interface monitor-traffic ether1 once paket benar-benar sampai ke router
RAW /ip firewall raw print stats paket kena rule RAW (drop/notrack/accept)
Conntrack /ip firewall connection print count-only entri koneksi dibuat
Filter /ip firewall filter print stats paket lolos RAW dan conntrack, lalu kena filter
NAT /ip firewall nat print stats paket diterjemahkan alamatnya

Tiga aturan bukti yang wajib dipegang sepanjang lab:

  1. Reset counter sebelum uji. Counter yang menumpuk dari kemarin tidak membuktikan apa pun.
  2. Satu uji, satu perubahan. Dua perubahan sekaligus membuat kesimpulan mustahil.
  3. Catat angka sebelum dan sesudah. Selisihnya yang jadi bukti, bukan angka akhirnya.

📊 Angka penting: plafon tabel koneksi 1.048.576 entri dan tumbuh sesuai kebutuhan. Timeout bawaan tcp-syn-sent 5 detik, udp 30 detik, icmp 10 detik, generic 10 menit, tcp-established 1 hari.

⚠️ Hati-hati: karena RAW jalan sebelum conntrack, rule action=drop di RAW tidak akan pernah muncul di /ip firewall connection. Sebaliknya, rule filter tidak akan pernah menghitung paket yang sudah dibuang RAW.

🧩 Istilah penting

Istilah Arti sederhana
RAW table Pemeriksaan paling awal, sebelum paket dicatat sebagai koneksi
Connection tracking Buku tamu koneksi: mencatat pasangan alamat, port, dan status
notrack Perintah "jangan catat paket ini", efek sampingnya besar
untracked Status paket yang dilewati conntrack, bukan new atau established
dst-limit Batas laju per aliran, di mana "aliran" ditentukan parameter mode
limit Batas laju global, semua paket berbagi satu ember
connection-limit Batas jumlah koneksi serentak, butuh conntrack
FastTrack Jalur cepat yang melewati firewall dan conntrack untuk paket lanjutan

🔧 Praktik: Lab 9 uji rusak terkontrol

Lab ini sengaja merusak konfigurasi. Jangan jalankan di router produksi, dan jangan jalankan di jam kerja kalau router itu dipakai orang lain.

Semua rule uji diberi komentar berawalan UJI- supaya mudah dibersihkan di akhir.

🔹 Persiapan lab dan baseline bukti

Topologi: router lab, satu laptop klien, satu PC server uji.

Perangkat Alamat Catatan
Router, ether1 (WAN) 192.0.2.10/24 gateway 192.0.2.1, rentang dokumentasi RFC 5737
Router, bridge-LAN 10.20.30.1/24 LAN lab
Laptop klien 10.20.30.20 mesin yang dipakai menguji
PC server uji 10.20.30.50 jalankan web server sederhana di port 443 atau 80

Konfigurasi dasar supaya lab menyerupai jaringan nyata: 

/ip address add address=192.0.2.10/24 interface=ether1
/ip address add address=10.20.30.1/24 interface=bridge-LAN
/ip route add gateway=192.0.2.1
/ip firewall nat add chain=srcnat out-interface=ether1 action=masquerade
/ip firewall filter add chain=forward connection-state=established,related action=accept
/ip firewall filter add chain=forward connection-state=invalid action=drop
/ip firewall filter add chain=forward in-interface=bridge-LAN out-interface=ether1 action=accept

Ambil baseline dan tulis di lembar hasil: 

/ip firewall raw print stats
/ip firewall filter print stats
/ip firewall nat print stats
/ip firewall connection print count-only
/ip firewall connection tracking print

💡 Tips: catat juga jam mulai uji. Saat membaca log nanti, urutan waktu sering lebih meyakinkan daripada hitungan paket.

🔹 Uji A: RAW drop sebelum conntrack

Tujuannya membuktikan bahwa paket yang dibuang RAW tidak pernah menyentuh conntrack. 

/ip firewall raw add chain=prerouting protocol=icmp src-address=10.20.30.20 \
  dst-address=192.0.2.1 action=drop log=yes log-prefix="UJI-A" comment="UJI-A"

Dari laptop klien, ping 192.0.2.1 sampai timeout. Lalu periksa: 

/ip firewall raw print stats where comment="UJI-A"
/ip firewall connection print count-only where src-address~"10.20.30.20"
/ip firewall filter print stats

Yang harus terlihat: counter rule UJI-A naik, entri koneksi untuk klien tetap nol, counter filter tidak berubah sama sekali.

📊 Angka penting: selisih counter RAW dibandingkan jumlah ping yang kamu kirim harus mendekati sama. Kalau kamu kirim 20 ping dan counter naik 40, berarti ada dua arah yang terhitung, atau ada paket lain yang ikut kena.

🧪 Uji cepat: :put [/ip firewall raw get [find comment="UJI-A"] packets]

Sekarang buang rule itu dan ganti dengan versi notrack untuk melihat bedanya: 

/ip firewall raw remove [find comment="UJI-A"]

🔹 Uji B: "tidak ada entri conntrack" bukan bukti RAW

Ini uji pembeda yang paling sering dilewatkan. Kita buat paket gagal tanpa menyentuh firewall sama sekali.

  1. Pastikan tidak ada rule UJI- yang aktif.
  2. Di laptop klien, ubah gateway menjadi 10.20.30.99 (alamat yang tidak ada).
  3. Ping 192.0.2.1 lagi sampai timeout.

Periksa berurutan: 

/interface monitor-traffic bridge-LAN once
/ip firewall raw print stats
/ip firewall connection print count-only where src-address~"10.20.30.20"
/ip arp print where address=10.20.30.99

Hasil yang diharapkan: counter RAW tetap nol, entri koneksi nol, dan ARP ke gateway palsu tidak lengkap. Paketnya memang tidak pernah sampai ke router.

Kesimpulannya penting. "Tidak ada entri conntrack" punya tiga penyebab berbeda:

  • paket dibuang RAW sebelum dicatat (Uji A),
  • paket ditandai notrack (Uji C),
  • paket tidak pernah sampai (Uji B).

⚠️ Hati-hati: sebelum menuduh firewall, lihat dulu counter interface dan tabel ARP. Banyak "masalah firewall" sebenarnya kabel, VLAN salah, atau gateway keliru di sisi klien.

🔹 Uji C: notrack mematikan NAT

Uji ini memperlihatkan efek samping paling mahal dari notrack. 

/ip firewall raw add chain=prerouting src-address=10.20.30.0/24 action=notrack comment="UJI-C"
/ip firewall filter add chain=forward connection-state=untracked action=log \
  log-prefix="UJI-C-UNTRACKED" place-before=0 comment="UJI-C-log"

Dari klien, buka situs apa pun. Hasilnya gagal, walaupun ping ke 192.0.2.1 tetap berhasil. Periksa buktinya: 

/ip firewall nat print stats
/ip firewall connection print count-only where src-address~"10.20.30.20"
/log print where message~"UJI-C-UNTRACKED"

Tiga bukti yang muncul bersamaan: counter srcnat tidak naik, tabel koneksi kosong untuk klien itu, dan log dipenuhi paket berstatus untracked.

Artinya paket keluar membawa alamat privat 10.20.30.20 apa adanya. Router di internet tidak tahu harus mengirim balasan ke mana, jadi balasan tidak pernah datang.

Fasilitas Efek saat notrack aktif
connection-state tidak bisa dipakai, paket dianggap untracked
NAT masquerade / src-nat / dst-nat tidak berlaku
Pencatatan pemakaian data hilang
FastTrack tidak bisa, karena butuh conntrack

💡 Tips: kalau tetap butuh notrack untuk trafik tertentu, pastikan jalur NAT tidak terkena. Persempit dengan src-address dan dst-address yang spesifik, jangan satu subnet penuh.

🔹 Uji D: RAW drop mengunci sesi sendiri

RAW tidak punya matcher connection-state. Konsekuensinya brutal: rule drop untuk port manajemen akan memutus sesi yang sedang kamu pakai, karena paket lanjutan sesi itu juga lewat prerouting.

Jangan langsung menempel rule-nya. Siapkan jalan pulang dulu: 

/system scheduler add name="batal-uji-d" interval=2m \
  on-event="/ip firewall raw disable [find comment=\"UJI-D\"]" \
  comment="UJI-D-penyelamat" disabled=no

Baru kemudian, dari Winbox atau SSH: 

/ip firewall raw add chain=prerouting protocol=tcp dst-port=22 action=drop comment="UJI-D"

Yang akan terjadi: sesi SSH yang sedang aktif langsung mati, bukan menunggu timeout. Dari Winbox di port 8291 kamu bisa melihat counter UJI-D terus naik.

Setelah dua menit, scheduler menonaktifkan rule itu sendiri. Kalau tidak, kamu akan terkunci dan harus reset lewat tombol fisik.

⚠️ Hati-hati: ini kesalahan yang paling sering membuat router "hilang". Aturan aman: setiap rule drop untuk port 22, 23, 8291, atau 443 di chain prerouting wajib punya pengecualian src-address atau in-interface-list=LAN di atasnya.

🔹 Uji E: membakar conntrack dan menghitung anggaran

Kita buktikan berapa cepat tabel koneksi terisi dan seberapa cepat kosong lagi. Dari laptop Linux: 

for i in $(seq 1 500); do (echo > /dev/tcp/192.0.2.1/$((20000+i))) 2>/dev/null & done

Sambil itu berjalan, di router: 

/ip firewall connection print count-only
:delay 10s
/ip firewall connection print count-only

Angka akan melonjak lalu turun sendiri. Penyebabnya timeout tcp-syn-sent hanya 5 detik. Inilah yang membedakan banjir koneksi pendek dari pemakaian wajar.

Sekarang hitung anggaran jaringanmu:

📊 Angka penting: 300 perangkat × 50 koneksi serentak = 15.000 entri, hanya 1,4% dari plafon 1.048.576. Yang membuat tabel jebol bukan jumlah perangkat, tapi koneksi berumur pendek yang datang lebih cepat daripada kecepatan timeout membersihkannya.

Lihat juga rasio di /ip firewall connection tracking print: bandingkan total-entries dengan max-entries. Kalau rasionya sudah di atas 70% pada jam sibuk, saatnya menambah rule pembatas, bukan menaikkan timeout.

💡 Tips: periksa juga enabled. Kalau nilainya no, semua pembahasan conntrack di artikel ini tidak berlaku, dan NAT ikut mati.

🔹 Uji F: dst-limit mode salah menyumbat semua

Ini persis kasus SMK di atas. Kita batasi HTTPS ke server uji.

Versi salah, mode dst-address: 

/ip firewall raw add chain=prerouting protocol=tcp dst-port=443 \
  dst-address=10.20.30.50 dst-limit=20,20,dst-address/1m \
  action=drop comment="UJI-F-salah"

Versi benar, mode src-address: 

/ip firewall raw add chain=prerouting protocol=tcp dst-port=443 \
  dst-address=10.20.30.50 dst-limit=20,20,src-address/1m \
  action=drop comment="UJI-F-benar"

Uji dengan tiga laptop membuka halaman server bersamaan. Pada versi salah, ketiganya tersendat karena berbagi satu ember 20 paket per detik. Pada versi benar, tiap IP punya ember sendiri.

Matcher Cara kerja
limit satu ember global, semua paket berbagi
dst-limit satu ember per aliran, aliran ditentukan mode

Perhatikan format penulisannya: rate[/time],burst,mode[/expire]. Kalau mode tidak ditulis, kamu kehilangan kendali atas siapa yang berbagi ember.

🧪 Uji cepat: /ip firewall raw print stats where comment~"UJI-F" — bandingkan laju kenaikan counter rule salah dan rule benar saat hanya satu klien yang sibuk.

🔹 Uji G: connection-limit bocor lewat notrack

Batas koneksi per host hanya bekerja pada trafik yang dilacak. 

/ip firewall filter add chain=forward protocol=tcp dst-port=443 \
  connection-limit=40,32 action=drop comment="UJI-G"

Pertama, tanpa notrack: buka banyak koneksi dari satu klien, rule UJI-G mulai menghitung dan memblokir di angka 40.

Sekarang aktifkan kembali rule UJI-C (notrack untuk subnet klien). Ulangi uji yang sama. Counter UJI-G tidak bergerak sama sekali, dan klien tetap bisa membuka ratusan koneksi.

Kesimpulannya: notrack bukan cuma mematikan NAT, tapi juga mematikan seluruh pengawasan berbasis koneksi — termasuk batas per host dan pencatatan pemakaian.

⚠️ Hati-hati: jangan pernah memasang notrack lebar-lebar di jaringan sekolah atau warnet yang mengandalkan pembatasan per siswa. Yang kamu matikan bukan hanya beban router, tapi juga kontrolmu.

🔹 Uji H: FastTrack memotong bukti

Uji ini menjelaskan kenapa counter bisa berhenti naik padahal trafik jalan normal. 

/ip firewall filter add chain=forward action=fasttrack-connection \
  connection-state=established,related place-before=0 comment="UJI-H"

Mulai unduhan besar dari laptop klien, lalu perhatikan: 

/ip firewall filter print stats where comment="UJI-H"
/ip firewall filter print stats where comment="UJI-G"
/ip firewall connection print count-only where src-address~"10.20.30.20"

Counter naik sebentar di awal koneksi, lalu berhenti. Unduhannya tetap jalan penuh. Paket lanjutan dari koneksi yang sudah di-fasttrack melewati pemrosesan firewall dan connection tracking.

📊 Angka penting: FastTrack hanya bekerja pada trafik yang butuh conntrack dan hanya di tabel routing main. Trafik untracked tidak bisa di-fasttrack, jadi dua uji ini saling mengunci.

Artinya, saat mendiagnosis, counter yang diam bukan bukti trafik mati. Cek dulu apakah koneksi itu sudah masuk jalur cepat.

🔹 Uji I: disiplin bukti dan connection-rate

Uji terakhir soal cara membaca, bukan cara mengonfigurasi. 

/ip firewall raw reset-counters-all
/ip firewall filter reset-counters-all
/ip firewall nat reset-counters-all

Lalu pasang penanda pemakai berat: 

/ip firewall filter add chain=forward protocol=tcp \
  connection-bytes=5000000-0 connection-rate=500k-2M \
  action=add-src-to-address-list address-list="berat" \
  address-list-timeout=10m comment="UJI-I"

Beberapa hal yang wajib diingat saat membaca hasilnya:

  • connection-rate hanya bekerja untuk TCP dan UDP, dan dihitung ulang tiap detik tanpa rata-rata.
  • connection-bytes menghitung dua arah termasuk header IP, jadi angkanya lebih besar dari ukuran file.
  • Unduhan cepat dalam waktu singkat akan kena; unduhan lambat tapi berjam-jam bisa lolos.

Karena itu pembatasan pemakai berat biasanya dipasang berlapis: connection-bytes untuk volume, connection-rate untuk kecepatan sesaat, dan queue untuk pembatasan yang adil.

💡 Tips: beri log-prefix yang unik per uji, misalnya UJI-I. Saat membaca /log print, kamu bisa langsung memisahkan bukti tanpa menebak.

🔹 Bersih-bersih dan lembar hasil

Jangan tinggalkan rule uji di router, walau kelihatannya tidak berbahaya. 

/ip firewall raw remove [find comment~"UJI-"]
/ip firewall filter remove [find comment~"UJI-"]
/system scheduler remove [find comment~"UJI-"]
/ip firewall address-list remove [find list="berat"]

Verifikasi tidak ada sisa: 

/ip firewall raw print where comment~"UJI-"
/ip firewall filter print where comment~"UJI-"

Lembar hasil yang harus kamu isi sendiri:

Uji Gejala Bukti pembeda Kesimpulan
A ping timeout counter RAW naik, conntrack nol dibuang sebelum conntrack
B ping timeout counter RAW nol, interface nol paket tidak pernah sampai
C internet mati, ping gateway hidup counter srcnat diam, log untracked NAT mati karena notrack
D SSH putus seketika counter rule naik pesat RAW tidak kenal established
E koneksi gagal saat ramai total-entries mendekati max-entries tabel koneksi penuh
F semua klien lambat bersamaan counter rule naik dari banyak sumber ember dibagi bersama
G batas koneksi tidak bekerja counter filter diam trafik untracked
H counter diam, trafik jalan counter naik lalu berhenti koneksi sudah di-fasttrack
I salah menuduh pemakai berat rate hanya TCP/UDP, tanpa rata-rata perlu bukti berlapis

🔹 Versi Winbox

Semua langkah di atas bisa dilakukan tanpa terminal:

  • Buka IP → Firewall → tab RAW. Kolom Packets dan Bytes adalah counter yang kita baca.
  • Tombol Reset Counters membersihkan angka sebelum uji. Ada juga Reset All Counters untuk semua tabel.
  • Tab Connections menampilkan entri koneksi sekaligus statusnya. Kolom Timeout berguna untuk melihat sisa umur entri.
  • Tab Tracking di bawah Firewall menunjukkan total-entries dan max-entries.
  • Untuk melihat beban, buka Tools → Profile dan lihat persentase waktu CPU di bagian firewall.
  • Log ada di Log, filter dengan kata kunci prefix uji.

✅ Verifikasi

Sebelum menutup lab, pastikan semuanya kembali normal:

  1. /ip firewall raw print where comment~"UJI-" menghasilkan daftar kosong.
  2. /ip firewall filter print where comment~"UJI-" juga kosong.
  3. /ip firewall nat print stats menunjukkan counter masquerade naik saat klien membuka internet.
  4. /ip firewall connection print count-only kembali ke angka wajar, bukan nol terus.
  5. Ping dari klien ke 192.0.2.1 berhasil, dan ping ke domain juga berhasil.
  6. /ip firewall connection tracking print menunjukkan enabled: yes.
  7. Tidak ada sesi SSH atau Winbox yang terputus saat konfigurasi disimpan.

🧪 Uji cepat: minta satu klien membuka halaman HTTPS, lalu jalankan /ip firewall connection print where dst-port=443. Kalau entri muncul dengan status established, jalur RAW, conntrack, dan NAT sudah sehat.

⚠️ Kesalahan umum & troubleshooting

Gejala Periksa dulu Penyebab & perbaikan
Ping mati, counter RAW nol dan counter interface nol kabel, VLAN, tabel ARP paket tidak sampai, bukan masalah firewall
Ping mati, interface naik, tapi conntrack nol rule notrack dan status enabled trafik sengaja dilewatkan atau conntrack mati
Internet mati setelah menambah rule RAW isi address-list=bogon daftar bogon memuat subnet LAN sendiri
Klien mengirim alamat privat ke internet counter srcnat notrack di jalur NAT, persempit atau hapus
SSH atau Winbox putus setelah simpan rule drop port manajemen RAW tidak punya connection-state, tambahkan pengecualian
Rule fragment=yes tidak pernah kena status conntrack conntrack merakit ulang fragmen, rule tidak akan match
Rule tls-host tidak match panjang segmen TLS jabat tangan terpecah ke beberapa segmen
connection-limit tidak menahan siapa pun status paket di tabel koneksi trafik untracked atau sudah di-fasttrack
Counter berhenti naik tapi trafik jalan rule fasttrack-connection paket lanjutan melewati firewall, bukan masalah
CPU tinggi walau rule RAW sedikit log=yes pada rule yang ramai logging per paket, matikan setelah uji
dst-limit menyumbat semua klien parameter mode mode dst-address, ganti ke src-address

🏭 Dipakai di dunia kerja

  • Sekolah: lab 40 PC dipakai try out serentak. Tanpa pembatas per host, satu siswa yang membuka banyak tab bisa menghabiskan jatah koneksi dan membuat seluruh ruang gagal login.
  • Kantor cabang: router tanpa admin tetap. Rule RAW yang salah bisa memutus akses remote, dan tidak ada yang bisa memperbaiki sampai besok pagi.
  • ISP dan RT-RW Net: pelanggan mengeluh lambat. Operator harus bisa membedakan gangguan di sisi pelanggan, di router, atau di uplink sebelum menaikkan paket.
  • Warnet: pembatasan per pelanggan bergantung pada conntrack. Satu rule notrack yang salah bisa mematikan seluruh sistem pembatasan tanpa terlihat.
  • Industri: jalur produksi memakai jaringan tertutup. Perubahan firewall harus dibuktikan di lab dulu, karena berhentinya satu switch berarti berhentinya satu lini.
  • Lab dan VPS provider: CHR dipakai untuk simulasi skala besar. Menghitung anggaran entri conntrack lebih murah daripada menambah RAM setelah layanan tumbang.

🔐 Catatan keamanan & etika

  • Lab ini mengubah perilaku jaringan secara nyata. Jalankan hanya di perangkat sendiri atau lab sekolah yang memang untuk praktik.
  • Jangan pernah memasang rule drop pada port manajemen tanpa menyiapkan akses kedua, misalnya konsol, port Winbox, atau scheduler penyelamat.
  • Aktifkan log=yes hanya selama uji. Log per paket pada trafik ramai memakan CPU dan memenuhi penyimpanan.
  • notrack menghilangkan jejak koneksi. Jangan memakainya pada jalur yang sedang dalam penyelidikan insiden, karena bukti ikut hilang.
  • Pembatasan trafik pengguna harus punya dasar kebijakan yang jelas dan diketahui pemilik jaringan, bukan keputusan sepihak admin.
  • Setiap perubahan pada router produksi sebaiknya lewat perubahan tercatat, bukan langsung di jam sibuk.

📌 Kesimpulan

  • RAW bekerja sebelum conntrack, jadi paket yang dibuang RAW tidak akan pernah muncul di tabel koneksi.
  • "Tidak ada entri conntrack" punya tiga penyebab: dibuang RAW, ditandai notrack, atau tidak pernah sampai.
  • notrack mematikan NAT, pencatatan pemakaian, batas koneksi, dan FastTrack sekaligus.
  • RAW tidak mengenal status koneksi, sehingga rule drop port manajemen memutus sesi yang sedang aktif.
  • Mode pada dst-limit menentukan siapa yang berbagi ember. Salah mode berarti semua pengguna sah ikut tersumbat.
  • Counter yang berhenti naik belum tentu trafik mati. Cek dulu apakah koneksi sudah di-fasttrack.

Langkah berikutnya: ambil satu rule RAW yang sudah ada di routermu, lalu buktikan dengan tiga counter — RAW, conntrack, dan filter — bahwa rule itu benar-benar menghemat kerja router, bukan hanya terlihat rapi di layar.

🔗 Materi terkait

📚 Referensi

Retrieved from "https://noctkj.net/index.php?title=Mikrotik_:_Praktikum_Uji_Firewall_RAW_dan_Diagnosa_Connection_Tracking&oldid=1461"