VPN disambungkan tetapi firewall masih menyekat: cara tahu yang mana

Klien berkata disambungkan, sumber masih menolak, dan langkah seterusnya yang biasa ialah mematikan sesuatu. Kedua-dua kawalan dalam ayat itu melakukan kerja berbeza: VPN membina laluan untuk trafik yang dilindungi, dan firewall memutuskan bagi setiap sambungan sama ada trafik boleh melalui. Tunel yang berfungsi dengan dasar yang menolak kelihatan sama seperti tunel rosak dari kerusi pengguna, jadi tugasan ialah mencari lapisan mana yang menjawab. Inilah urutan yang saya ikuti, dengan bacaan yang memberitahu anda supaya berhenti.

Pisahkan laluan daripada dasar

Mulakan dengan bentuk kegagalan, kerana itu maklumat percuma. Paket yang digugurkan menghasilkan tamat masa: klien cuba lagi, tiada apa kembali, dan arahan tergantung sehingga menyerah. Penolakan menghasilkan keengganan atau set semula: sesuatu menjawab dan berkata tidak. Perkhidmatan yang tidak mendengar menolak pada hos itu sendiri, tanpa sebarang firewall.

Ketiga-tiga hasil itu menunjuk ke lapisan berbeza. Tamat masa bermaksud ada dasar di suatu tempat membuang secara senyap, atau laluan tidak pernah meninggalkan mesin. Ditolak bermaksud anda sampai ke hos dan timbunannya atau firewall hosnya menolak. Kesunyian sepenuhnya, dengan antara muka tunel hidup dan tiada laluan ke destinasi, bermaksud laluan itu salah dan tiada peraturan firewall akan membaikinya.

Baca laluan dalam satu lintasan

Sahkan tunel meliputi destinasi sebelum melihat satu peraturan pun. Tunel berpecah yang hanya membawa subnet pejabat tidak akan menghalakan permintaan ke julat lain, dan kegagalan itu kemudian kelihatan seperti sekatan firewall yang bukan:

ip route get 10.20.4.15
ip -brief address show
wg show
sudo ipsec statusall

Keluaran laluan menamakan antara muka yang akan dilalui paket dan alamat sumber yang akan dibawanya. Jika antara muka itu kad rangkaian fizikal anda dan bukan tunel, masalahnya ada pada penghalaan atau julat yang dibenarkan tunel, dan ia tergolong dalam konfigurasi VPN dan bukan firewall.

Satu perangkap khusus VPN wajar diperiksa sendiri. Dalam WireGuard, AllowedIPs sesuatu peer ialah laluan dan penapis kriptografi sekali gus: paket yang alamat sumbernya tidak sepadan dengan set yang dibenarkan peer digugurkan sebelum mana-mana peraturan firewall dirujuk. Jadi firewall hos yang betul sepenuhnya boleh berada di belakang pengguguran senyap yang kelihatan seperti dasar, dan pembaikannya ialah satu baris konfigurasi kunci dan bukan peraturan.

Baca dasar pada lapisan yang menjawab

Setelah laluan betul, telusuri dasar dari hos ke luar dan perhatikan satu lapisan yang pembilangnya bergerak:

ss -ltn | grep ':443'
sudo nft list ruleset
sudo iptables -S INPUT
sudo ufw status verbose

Soket yang mendengar menjawab soalan berbeza daripada peraturan. Jika tiada apa mendengar pada port, kernel menolak sambungan dan tiada peraturan masuk yang relevan. Jika soket wujud dan sambungan daripada klien jauh tamat masa, pengguguran berlaku di suatu tempat pada laluan, dan pembilang peraturan memberitahu anda sama ada ia berlaku di sini.

Hidupkan pengelogan untuk profil atau rantai yang anda syaki dan bukan meneka dari luar. Satu pengguguran tercatat yang menamakan sumber, destinasi dan port mengenal pasti lapisan dan peraturan, dan ia juga membuktikan paket itu tiba, yang tidak dapat ditentukan oleh mana-mana ujian di pihak klien.

Baca keputusan gateway apabila tunel berakhir di situ

Pada gateway tapak-ke-tapak atau akses jauh, VPN mengesahkan pengguna dan dasar memberi kuasa kepada sumber, dan itu pemberian yang berasingan. Pengguna yang dibenarkan masuk ke tunel tidak dibenarkan secara automatik ke setiap hos dalaman, dan penolakan sering datang daripada peraturan penghantaran semasa tunel itu sendiri sihat. Pemisahan yang sama muncul dalam IPsec, di mana dasar keselamatan yang memilih trafik berbeza daripada penapis yang membenarkannya, dan itulah sebabnya kedua-duanya didokumenkan sebagai mekanisme berbeza di RFC 4301.

Periksa laluan balik dengan teliti seperti laluan keluar. Penapisan berkeadaan perlu melihat balasan, jadi penghalaan tak simetri melalui tunel ke satu arah dan mengelilinginya ke arah lain menghasilkan pengguguran yang kelihatan rawak dan hanya berulang daripada sesetengah klien. Jika trafik sampai ke gateway dan berhenti, baca peraturan penghantaran dan laluan balik bersama-sama sebelum meluaskan apa-apa.

Gateway juga tempat peraturan NAT atau penyamaran boleh menyembunyikan sumber sebenar. Jika hos dalaman nampak alamat gateway dan bukan klien, peraturan firewall hos mereka yang sepatutnya sepadan dengan kumpulan klien tidak akan pernah sepadan, dan pembaikannya terletak pada gateway dan bukan pada setiap pelayan.

Ubah lapisan paling sempit, kemudian sahkan

Bertahanlah daripada pembaikan luas. Mematikan firewall hos, menambah peraturan yang membenarkan semua, atau memaksa setiap antara muka ke profil dipercayai masing-masing membuang kawalan yang sedang menjalankan tugasnya, dan perubahan itu hidup lebih lama daripada insiden. Peraturan yang terhad kepada julat sumber dan port berkenaan lebih mudah disemak, lebih mudah dibuang, dan membiarkan baki dasar mesin itu utuh.

Sahkan dengan ujian yang sama yang gagal, daripada klien yang sama, dan kemudian sekali lagi selepas menyambung semula, kerana peraturan yang sepadan sebelum tunel berunding semula boleh berhenti sepadan selepasnya:

nc -vz 10.20.4.15 443
curl -v --max-time 5 https://10.20.4.15/

Sebelum menutupnya:

• Laluan ke destinasi keluar melalui antara muka tunel, dan alamat sumber sepadan dengan apa yang dijangka oleh dasar.
• Sesuatu mendengar pada port, dan penolakan atau tamat masa dikaitkan dengan peraturan bernama dan bukan diandaikan.
• Gateway menghantar ke kedua-dua arah, dan destinasi melihat sumber yang peraturan anda ditulis untuknya.
• Tiada kawalan dimatikan supaya ujian lulus, dan perubahan yang anda buat menamakan satu julat sumber dan satu port.