Aturan port 80 dan 443 tidak mengirim peramban melalui VPN

Seseorang meminta peramban memakai terowongan, dan permintaan itu kembali sebagai aturan firewall yang cocok dengan port tujuan 80 dan 443. Tampak tepat dan tidak. Pencocokan port memilih paket berdasarkan tajuk transportnya, bukan berdasarkan program yang membuka soket, dan penjelajahan modern tidak membatasi diri pada dua port itu di TCP. Aturan itu akan melewatkan sebagian lalu lintas yang ingin Anda sertakan dan menangkap lalu lintas yang tidak pernah ingin Anda sentuh. Sebelum menulisnya, putuskan batas mana dari tiga batas berbeda yang sebenarnya Anda inginkan.

Aturan itu menjelaskan kelas transport, bukan aplikasi

Di Linux, pencocokan port tujuan memeriksa tajuk TCP dan tidak ada apa pun di atasnya. Menandai paket-paket itu dan mengarahkannya dengan rute kebijakan bekerja persis seperti yang didokumentasikan, dan tidak satu pun mesin itu tahu apa arti muatan atau proses mana yang mengirimnya. Tanda adalah angka yang dilekatkan pada paket, bukan identitas 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 konsekuensi langsung menyusul. Pembaru perangkat lunak yang menghubungi TCP 443 mendapat perlakuan sama seperti peramban, yang mungkin baik-baik saja atau mungkin gangguan yang menunggu siklus pembaruan berikutnya. Dan layanan web yang sengaja diterbitkan di port lain, katakanlah 8443, sepenuhnya di luar aturan padahal masih lalu lintas web yang dipedulikan pengguna.

Angka-angka itu pemilih yang sah ketika persyaratannya memang tentang port tersebut. Mereka menjadi fiksi ketika di tiket tertulis «peramban» dan di kumpulan aturan diterapkan rentang port. Kesenjangan itu bukan kehalusan dokumentasi. Itu adalah perbedaan antara aturan yang dapat Anda pertahankan dalam tinjauan dan aturan yang tidak dapat diuji siapa pun.

HTTP/3 diam-diam meninggalkan aturan TCP Anda

HTTP/3 berjalan di atas QUIC, dan QUIC diangkut dalam UDP. Aturan yang hanya cocok dengan TCP tidak dapat melihatnya, jadi peramban yang sama yang lolos halaman uji Anda dapat mengirim permintaan berikutnya lewat UDP dan melewati terowongan tanpa siapa pun mengubah pengaturan. RFC 9114 menjelaskan HTTP/3 sebagai protokol berbasis QUIC, dan QUIC memakai UDP dengan port bawaan 443 dalam penerapan umum.

Apakah peramban tertentu mencoba HTTP/3 bergantung pada konfigurasinya, pada situsnya, dan pada apakah percobaan sebelumnya berhasil. Itu membuatnya hal buruk untuk dinalar dari ingatan. Tanyakan saja kepada alatnya:

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 dinegosiasikan, jadi 3 memastikan jalur UDP dipakai. Daftar soket lalu menunjukkan apakah koneksi itu terikat ke antarmuka terowongan atau ke antarmuka fisik. Jika HTTP/3 tidak tersedia dalam build curl Anda, tanda itu gagal dengan berisik alih-alih mundur diam-diam, yang merupakan rahmat kecilnya sendiri.

DNS adalah keputusan terpisah yang harus Anda ambil

Aturan port untuk lalu lintas web tidak mengatakan apa pun tentang resolusi nama. Peramban dapat memakai penyelesai sistem, penyelesai yang dikonfigurasi di dalam peramban, atau yang didorong oleh koneksi terakhir. Masing-masing dapat mengirim kueri lewat jalur berbeda dari yang dipilih aturan Anda, yang menghasilkan perpecahan klasik: halaman termuat, nama diselesaikan di tempat yang tidak Anda duga, dan situs internal diselesaikan ke alamat publik atau tidak sama sekali.

Putuskan secara eksplisit. Jika nama internal harus diselesaikan melalui terowongan, penyelesai harus berada di dalamnya, dan kumpulan aturan harus mengizinkan DNS ke penyelesai itu sambil menahan kueri lain di luar. Jika peramban memakai DNS over HTTPS ke penyedia publik, kueri sepenuhnya melewati penyelesai Anda dan aturan port tidak dapat membantu. Tulis pilihan itu dalam catatan perubahan yang sama dengan aturan perutean, karena keduanya dibaca bersama oleh siapa pun yang men-debug kegagalan berikutnya.

Lalu verifikasi dengan penyelesai, bukan dengan halaman:

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

Jawaban yang hilang adalah masalah resolusi bahkan ketika pesan galat peramban menyalahkan jaringan. Dua kegagalan itu tampak identik bagi pengguna dan merupakan tiket yang sama sekali berbeda.

Tiga batas, tiga mekanisme berbeda

Sebagian besar kebingungan hilang begitu Anda menamai batas yang Anda inginkan. Ketiganya tidak dapat dipertukarkan, dan masing-masing punya mode kegagalan berbeda saat terowongan putus.

Profil peramban terpisah adalah jebakan di baris tengah. Ia memisahkan cookie dan riwayat, dan tidak mengubah apa pun pada tabel perutean host, jadi kedua profil menempuh jalur yang sama. Isolasi memerlukan sesuatu yang ditegakkan kernel, yakni ruang nama, kontainer, atau aplikasi yang memiliki antarmuka terowongannya sendiri.

Baris mana pun yang berlaku, tuliskan apa yang harus terjadi ketika terowongan jatuh. Rute berbasis tanda yang hilang bersama antarmuka biasanya kembali ke rute bawaan fisik, yang merupakan perilaku fail-open. Itu mungkin dapat diterima untuk penjelajahan dan tidak dapat diterima untuk hal lain, dan itu keputusan, bukan rincian implementasi.

Uji aliran yang Anda klaim tercakup

Uji penerimaan harus mengikuti batas yang Anda tuliskan, bukan nomor port yang nyaman. Pilih satu aliran yang harus lewat terowongan, satu yang tidak boleh, dan satu yang memakai transport yang tidak Anda pikirkan:

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'

Pencarian rute memberi tahu antarmuka mana yang sebenarnya dipakai sebuah tujuan, dan itulah fakta yang paling sering salah dalam laporan. Baris curl memastikan versi yang dinegosiasikan dan keluarga alamat. Cetakan kumpulan aturan menangkap aturan yang Anda tambahkan saat pengujian dan lupa dibatasi, dan begitulah tanda sementara berubah menjadi perutean fail-open permanen.

Catat ketiga keluaran dengan stempel waktu dan simpan bersama perubahan. Ketika nanti seseorang melaporkan bahwa «VPN merusak intranet», perbedaan antara batas yang dimaksudkan dan yang diterapkan akan terlihat dalam catatan itu, dan perbaikannya akan berupa perubahan aturan, bukan perdebatan.