Peraturan port 80 dan 443 tidak menghantar pelayar melalui VPN

Seseorang meminta pelayar menggunakan terowong, dan permintaan itu kembali sebagai peraturan tembok api yang sepadan dengan port destinasi 80 dan 443. Ia kelihatan tepat dan tidak. Padanan port memilih paket berdasarkan pengepala pengangkutannya, bukan berdasarkan program yang membuka soket, dan pelayaran moden tidak terhad kepada dua port itu pada TCP. Peraturan itu akan terlepas sebahagian trafik yang anda mahu sertakan dan menangkap trafik yang anda tidak pernah berniat menyentuh. Sebelum menulisnya, tentukan sempadan mana antara tiga sempadan berbeza yang sebenarnya anda mahu.

Peraturan itu menerangkan kelas pengangkutan, bukan aplikasi

Di Linux, padanan port destinasi memeriksa pengepala TCP dan tiada apa di atasnya. Menanda paket itu dan mengarahkannya dengan laluan dasar berfungsi tepat seperti didokumenkan, dan tiada satu pun jentera itu tahu apa maksud muatan atau proses mana yang menghantarnya. Tanda itu ialah nombor yang dilekatkan pada paket, bukan identiti yang dilekatkan pada aplikasi.

nft add rule inet mangle output tcp dport { 80, 443 } meta mark set 0x1
ip rule add fwmark 0x1 table 100
ip route add default dev wg0 table 100

Dua akibat menyusul serta-merta. Pengemas kini perisian yang menghubungi TCP 443 menerima layanan sama seperti pelayar, yang mungkin baik atau mungkin gangguan yang menunggu kitaran kemas kini seterusnya. Dan perkhidmatan web yang diterbitkan dengan sengaja pada port lain, katakanlah 8443, jatuh sepenuhnya di luar peraturan walaupun ia masih trafik web yang dipedulikan pengguna.

Nombor-nombor itu pemilih yang sah apabila keperluan benar-benar tentang port tersebut. Ia menjadi fiksyen apabila tiket menulis «pelayar» dan julat port dilaksanakan dalam set peraturan. Jurang itu bukan kehalusan dokumentasi. Ia ialah perbezaan antara peraturan yang boleh anda pertahankan dalam semakan dan peraturan yang tiada siapa boleh uji.

HTTP/3 meninggalkan peraturan TCP anda secara senyap

HTTP/3 berjalan di atas QUIC, dan QUIC dibawa dalam UDP. Peraturan yang hanya sepadan dengan TCP tidak dapat melihatnya, jadi pelayar yang sama yang lulus halaman ujian anda boleh menghantar permintaan kemudian melalui UDP dan memintas terowong tanpa sesiapa menukar tetapan. RFC 9114 menerangkan HTTP/3 sebagai protokol berasaskan QUIC, dan QUIC menggunakan UDP dengan port lalai 443 dalam penggunaan biasa.

Sama ada pelayar tertentu cuba HTTP/3 bergantung pada konfigurasinya, pada laman, dan pada sama ada percubaan sebelumnya berjaya. Itu menjadikannya perkara buruk untuk ditakrif dari ingatan. Tanyalah alat itu:

curl --http3 -sS -o /dev/null -w '%{http_version} %{time_total}\n' https://example.com
ss -tunp | grep -E ':443\b'

Baris curl mencetak versi yang dirundingkan, jadi 3 mengesahkan laluan UDP digunakan. Senarai soket kemudian menunjukkan sama ada sambungan itu terikat pada antara muka terowong atau yang fizikal. Jika HTTP/3 tiada dalam binaan curl anda, bendera itu gagal dengan kuat dan bukannya berundur secara senyap, yang merupakan belas kasihannya yang kecil.

DNS ialah keputusan berasingan yang perlu anda buat

Peraturan port untuk trafik web tidak mengatakan apa-apa tentang penyelesaian nama. Pelayar boleh menggunakan penyelesai sistem, penyelesai yang dikonfigurasikan dalam pelayar, atau yang ditolak oleh sambungan terakhir. Setiap daripadanya boleh menghantar pertanyaan melalui laluan berbeza daripada yang dipilih peraturan anda, yang menghasilkan perpecahan klasik: halaman dimuatkan, nama diselesaikan di tempat yang anda tidak jangkakan, dan laman dalaman diselesaikan ke alamat awam atau tidak sama sekali.

Putuskannya secara eksplisit. Jika nama dalaman mesti diselesaikan melalui terowong, penyelesai mesti berada di dalamnya, dan set peraturan mesti membenarkan DNS ke penyelesai itu sambil menahan pertanyaan lain di luar. Jika pelayar menggunakan DNS over HTTPS ke penyedia awam, pertanyaan itu memintas penyelesai anda sepenuhnya dan peraturan port tidak dapat membantu. Tulis pilihan itu dalam rekod perubahan yang sama dengan peraturan penghalaan, kerana kedua-duanya dibaca bersama oleh sesiapa yang menyahpepijat kegagalan seterusnya.

Kemudian sahkan dengan penyelesai dan bukan dengan halaman:

resolvectl query intranet.example.internal
resolvectl status | grep -A3 'Current DNS Server'

Jawapan yang tiada ialah masalah penyelesaian walaupun mesej ralat pelayar menyalahkan rangkaian. Kedua-dua kegagalan itu kelihatan serupa kepada pengguna dan merupakan tiket yang sama sekali berbeza.

Tiga sempadan, tiga mekanisme berbeza

Sebahagian besar kekeliruan hilang sebaik sahaja anda menamakan sempadan yang anda mahu. Ia tidak boleh ditukar ganti, dan setiap satu mempunyai cara kegagalan berbeza semasa gangguan terowong.

Profil pelayar berasingan ialah perangkap di baris tengah. Ia memisahkan kuki dan sejarah, dan ia tidak mengubah apa-apa pada jadual penghalaan hos, jadi kedua-dua profil melalui laluan yang sama. Pengasingan memerlukan sesuatu yang dikuatkuasakan kernel, iaitu ruang nama, kontena atau aplikasi yang memiliki antara muka terowongnya sendiri.

Baris mana pun yang berlaku, tuliskan apa yang harus berlaku apabila terowong jatuh. Laluan berasaskan tanda yang hilang bersama antara muka biasanya kembali ke laluan lalai fizikal, yang merupakan tingkah laku fail-open. Itu mungkin boleh diterima untuk pelayaran dan tidak boleh diterima untuk apa-apa lagi, dan ia keputusan, bukan butiran pelaksanaan.

Uji aliran yang anda dakwa diliputi

Ujian penerimaan mesti mengikut sempadan yang anda tulis, bukan nombor port yang memudahkan. Pilih satu aliran yang mesti melalui terowong, satu yang tidak boleh, dan satu yang menggunakan pengangkutan yang anda tidak fikirkan:

ip route get 203.0.113.40
curl -sS -o /dev/null -w 'v4 %{http_version} %{remote_ip}\n' https://example.com
nft list ruleset | grep -A2 'dport'

Carian laluan memberitahu anda antara muka mana yang sebenarnya digunakan oleh destinasi, dan itulah fakta yang paling banyak disalah sebut dalam laporan. Baris curl mengesahkan versi yang dirundingkan dan keluarga alamat. Longgokan set peraturan menangkap peraturan yang anda tambah semasa ujian dan terlupa dibataskan, dan begitulah tanda sementara menjadi penghalaan fail-open kekal.

Rekodkan ketiga-tiga keluaran dengan cap masa dan simpan bersama perubahan. Apabila kemudian seseorang melaporkan bahawa «VPN merosakkan intranet», perbezaan antara sempadan yang dimaksudkan dan yang dilaksanakan akan kelihatan dalam rekod itu, dan pembetulannya akan menjadi perubahan peraturan, bukan perdebatan.