Sakelar darurat hanya memblokir IPv4: mengapa IPv6 tetap lolos

Terowongan putus, sakelar darurat melaporkan bahwa ia aktif, dan unduhan terus berjalan. Tidak ada yang rusak pada aturan IPv4. Aplikasi hanya berpindah ke jalur yang tidak pernah ditulis oleh aturan tersebut.

Perangkat dual-stack memiliki dua jalur keluar yang independen. Memblokir salah satunya adalah blokir setengah.

Dua set aturan, dua nilai bawaan

Di Linux, iptables dan ip6tables adalah tabel terpisah dengan kebijakan terpisah. Menetapkan rantai INPUT dan OUTPUT tabel IPv4 ke DROP tidak mengubah apa pun di tabel IPv6, yang nilai bawaannya biasanya ACCEPT. Pemisahan yang sama ada di nftables, di mana Anda dapat memeriksa satu keluarga dan menemukan bahwa hanya satu di antaranya membawa aturan Anda. Asimetri itu normal, dan itulah seluruh masalahnya.

Itulah sebabnya sakelar darurat bisa tampak menyeluruh tetapi berperilaku sebagian. Skrip yang menulis aturan IPv4 berjalan, penghitung bertambah, baris log muncul, dan paket IPv6 keluar melalui antarmuka fisik sama sekali tidak tersentuh.

Baca apa yang benar-benar dipasang klien Anda, bukan apa yang dijanjikan halaman pemasaran. Beberapa klien merutekan IPv6 ke dalam terowongan, sebagian sengaja memblokirnya, dan sebagian membiarkannya sementara penguncian tingkat platform memberlakukan aturan berbeda. Dokumentasi vendor adalah satu-satunya sumber yang layak dipercaya di sini.

Apa yang dikatakan konfigurasi antarmuka kepada Anda

Halaman manual wg-quick menyertakan aturan IPv6 dalam konfigurasi contohnya, dan alasannya persis celah ini. Contoh itu bukan hiasan. Itu ada karena aturan IPv4 saja akan membiarkan keluarga kedua terbuka.

Menyalin separuh contoh menghasilkan separuh kebijakan. Inilah asal paling umum dari kebocoran ini. Sebuah pos blog memotong contoh demi panjang. Versi yang dipotong kemudian menjadi templat yang dipakai ulang semua orang.

# what is actually installed, per family?
sudo iptables -S OUTPUT | head -20
sudo ip6tables -S OUTPUT | head -20

# nftables: inspect each family separately
sudo nft list ruleset inet | head -40

# does this host even have a usable IPv6 path?
ip -6 route show default

Jika perintah kedua mencetak kebijakan permisif sementara yang pertama mencetak DROP, Anda telah menemukan jawabannya tanpa menyentuh klien. Asimetri itulah bugnya.

Mengapa satu pencarian bukan seluruh cerita

Satu nama dapat mengembalikan catatan A dan catatan AAAA sekaligus, dan aplikasi tidak semuanya memilih dengan cara yang sama. Peramban dapat memilih IPv6 ketika jaringan menawarkannya dan mundur saat gagal, sementara sinkronisasi latar belakang atau pembaru memakai penyelesai dan preferensinya sendiri. Karena itu, satu uji berhasil melalui IPv4 membuktikan satu jalur, bukan kebijakannya.

Transisi jaringan juga mengubah jawabannya. Bergabung ke jaringan Wi-Fi lain, bangun dari tidur, atau beralih ke seluler dapat memberi perangkat prefiks IPv6 baru, dan kebijakan yang tampak memadai di LAN kantor mungkin tidak mencakupnya.

Uji keadaan saat terowongan mati

Menguji saat terhubung memberi tahu Anda bahwa terowongan bekerja. Uji yang menarik adalah keadaan tidak tersedia, karena saat itulah sakelar darurat seharusnya bertahan. Hentikan terowongan dengan sengaja, lalu coba tujuan yang penting dari aplikasi yang Anda lindungi.

# with the tunnel stopped, does anything still leave?
ip -6 route get 2606:4700:4700::1111
curl -6 -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://ipv6.example.net/
curl -4 -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://ipv4.example.net/

Kedua keluarga seharusnya gagal tertutup. Jika permintaan IPv4 kehabisan waktu dan permintaan IPv6 mengembalikan kode status, kebijakannya tidak lengkap, dan tidak ada jumlah pengujian ulang terowongan yang akan mengubahnya.

Pertahankan juga pengecualian yang terdokumentasi dalam uji itu. Penemuan jaringan lokal, pembaruan DHCP, atau jalur bootstrap ke titik akhir VPN mungkin perlu tetap dapat dijangkau, dan pengecualian itu harus disebutkan dalam kebijakan alih-alih ditemukan saat gangguan. Uji kebocoran yang gagal karena terowongan tidak dapat naik lagi bukan temuan keamanan, melainkan temuan konektivitas.