Kill switch di router yang mencakup FORWARD, OUTPUT, dan IPv6

Anda masuk ke router, menempel satu set aturan kill switch dari kiriman forum, dan LAN berhenti menjelajah begitu tunnel putus. Dua hari kemudian router masih memperbarui catatan DNS dinamisnya lewat WAN biasa, dan laptop tamu masih menjangkau situs IPv6. Kedua perilaku itu normal, karena aturan yang ditempel hanya mencakup satu rantai dan satu keluarga alamat, dan tidak satu pun dari itu adalah seluruh router. Menelusuri jalur paket secara berurutan menunjukkan tepat apa yang terlewat.

Mulailah dari router, bukan dari laptop

Kebijakan di tingkat router menarik bagi kantor kecil karena setiap perangkat di belakangnya mewarisi perilaku yang sama dan tidak ada yang bisa lupa mengaktifkan sakelar di klien. Ini juga memberi Anda satu tempat untuk menguji setelah setiap pembaruan firmware. Yang tidak diberikannya adalah cakupan otomatis atas lalu lintas router itu sendiri atau keluarga alamat kedua, dan itulah dua celah di balik sebagian besar penerapan yang gagal.

Sebelum menyunting apa pun, catat tiga fakta di kertas: nama antarmuka WAN, nama jembatan LAN, serta alamat dan port titik akhir VPN. Anda akan memerlukan ketiganya di dalam aturan, dan menebak nama antarmuka adalah alasan paling umum sebuah set aturan yang tampak benar tidak melakukan apa pun.

Telusuri tiga jalur yang dapat dilalui paket

Lalu lintas dari laptop ke internet diteruskan, jadi melewati rantai FORWARD. Lalu lintas yang dihasilkan router sendiri, seperti penerusan DNS, kueri NTP, pembaruan DDNS, dan kanal kendali VPN, melewati OUTPUT. Lalu lintas manajemen yang ditujukan ke router masuk melalui INPUT.

Jadi kill switch yang dibangun hanya di FORWARD melindungi klien dan tidak yang lain. Tabel menunjukkan mengapa kebocoran pada adegan pembuka dapat diprediksi, bukan misterius.

Pada sebagian besar rancangan Anda tidak perlu kill switch di INPUT, tetapi Anda perlu menjaga akses manajemen tetap berjalan selama tunnel mati. Jika tidak, saat VPN gagal pertama kali, Anda berkendara ke kantor dengan kabel konsol.

Urutkan aturan agar tunnel tetap bisa naik

Kill switch yang berfungsi adalah daftar izin yang berakhir dengan penolakan, dan urutannya yang membuatnya menjadi kill switch, bukan bata. Izinkan loopback, titik akhir VPN, balasan untuk aliran yang sudah terbentuk, dan antarmuka tunnel lebih dulu; tolak sisanya terakhir.

iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -d 198.51.100.7 -p udp --dport 51820 -j ACCEPT
iptables -A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o wg0 -j ACCEPT
iptables -A OUTPUT -o eth0 -j REJECT

Pada tahap ini titik akhir harus berupa alamat, bukan nama host. Begitu penolakan terakhir memblokir DNS, aturan yang menyebut nama host penyedia tidak bisa lagi diselesaikan, dan tunnel tidak pernah menyala lagi setelah reboot. Jika penyedia merotasi titik akhir, selesaikan nama itu sebelum kebijakan diterapkan dan segarkan aturan tersebut dari skrip yang sama.

Cerminkan bentuk yang sama di FORWARD untuk lalu lintas klien, dan tempatkan aturan manajemen eksplisit di atas penolakan. Jaga aturan manajemen itu sempit tetapi terjangkau, dan konfirmasikan dengan membuka sesi SSH kedua sebelum menutup yang pertama. Terkunci di luar selama perubahan kill switch cukup umum untuk direncanakan. Pada router yang menjalankan WireGuard, allowed-ips milik peer menentukan apa yang masuk ke tunnel, sedangkan aturan ini menentukan apa yang boleh keluar tanpanya.

IPv6 butuh pintunya sendiri

Semua di atas adalah IPv4. Jika LAN Anda memiliki IPv6 yang berfungsi dan tunnel hanya membawa IPv4, setiap perangkat yang tercakup tetap memiliki rute langsung ke internet yang tidak pernah dilihat aturan baru Anda. Laptop dual-stack akan dengan senang hati memilihnya, dan kill switch hanya akan tampak rusak bagi orang yang menguji dengan IPv4.

ip6tables -A FORWARD -i br-lan -j REJECT
ip6tables -A OUTPUT -o eth0 -j REJECT
ip6tables -A OUTPUT -o lo -j ACCEPT

Urutan juga penting di sini: izin loopback harus mendahului penolakan WAN, atau layanan lokal di router mulai gagal dengan cara yang aneh. Jika jaringan sama sekali tidak menggunakan IPv6, menonaktifkannya di WAN dan LAN lebih sederhana dan tidak menyisakan apa pun untuk dilupakan.

Beberapa klien VPN memasang rute default hanya untuk IPv4 dan membiarkan rute default IPv6 yang ada tidak tersentuh. Periksa tabel perutean setelah tunnel terhubung alih-alih menganggap klien sudah menanganinya.

Buktikan dengan tunnel mati

Hentikan tunnel dari router dan uji dari tiga tempat dalam urutan ini:

# systemctl stop wg-quick@wg0
# ip route get 203.0.113.1
# curl -m 5 -sS http://example.com || echo blocked
# iptables -vnL OUTPUT | head
# ip6tables -vnL OUTPUT | head

Pencarian rute memberi tahu Anda ke mana paket akan pergi, dan penghitung memberi tahu Anda apakah aturan Anda pernah cocok. Aturan dengan nol paket setelah uji yang gagal tidak melindungi apa pun, dan penyebab biasanya adalah nama antarmuka yang berbeda dari yang Anda ketik. Uji secara eksplisit lalu lintas yang dihasilkan router, karena uji dari sisi LAN tidak dapat menjalankan OUTPUT.

Putuskan mode kegagalan sebelum Anda membutuhkannya. Fail-closed menjaga klien tetap offline sampai tunnel kembali; fail-open memulihkan akses WAN biasa dan menggagalkan tujuan untuk lalu lintas yang Anda pedulikan. Rute blackhole ke pool VPN dengan metrik tinggi adalah lapisan kedua yang berguna untuk rancangan fail-closed, karena tetap bertahan saat rute tunnel hilang alih-alih kembali ke rute default.

Terima penyiapan hanya ketika klien LAN, permintaan yang dihasilkan router, dan permintaan IPv6 semuanya gagal dengan tunnel mati, dan ketiganya berfungsi lagi begitu tunnel naik.