Port VPN mana yang perlu dibuka pada firewall: protokol demi protokol

Dua peraturan berasingan menentukan sama ada terowong VPN dapat melepasi firewall: port yang didail oleh klien dan protokol yang membawa muatan. Buka yang pertama sahaja dan terowong akan disahkan, tetapi selepas itu tiada data bergerak. Minimumnya ialah satu port TCP serta GRE untuk PPTP, dua port UDP serta ESP untuk L2TP/IPsec dan IKEv2, dan satu port untuk SSTP, OpenVPN serta WireGuard. Arah, penjejakan keadaan dan NAT menentukan selebihnya.

Mulakan dengan port yang didail klien

Setiap keluarga mempunyai titik masuk yang dihubungi klien dahulu, dan titik masuk itulah yang perlu dinamakan oleh peraturan kebenaran anda. Klien PPTP bersambung ke TCP 1723. L2TP/IPsec memulakan IKE pada UDP 500 dan beralih ke UDP 4500 apabila lintasan NAT digunakan, manakala rangka L2TP sendiri berada pada UDP 1701 di dalam terowong. SSTP membalut sesi dalam TLS pada TCP 443, IKEv2 berunding pada UDP 500 dan 4500, OpenVPN menggunakan UDP 1194 secara lalai tetapi sering dipindahkan ke TCP 443, dan WireGuard mendengar pada UDP 51820.

Anggap nombor itu sebagai nilai lalai, bukan sifat tetap. Antara muka WireGuard menggunakan mana-mana port mendengar yang diisytiharkan oleh konfigurasinya, dan pelayan OpenVPN boleh duduk pada mana-mana port yang dipilih pentadbir. Baca konfigurasi pelayan sebelum menulis peraturan, kerana firewall yang dibuka untuk 1194 tidak berguna bagi pelayan yang dipindahkan ke 443.

Lajur ketiga ialah tempat kebanyakan tiket perubahan tersasar. Peraturannya wujud, tetapi ia menunjuk ke destinasi yang salah, arah yang salah atau pengangkutan yang salah.

GRE dan ESP ialah nombor protokol, bukan port

GRE dan ESP langsung tidak mempunyai port, jadi borang firewall yang hanya menerima nombor port tidak dapat menyatakannya. GRE ialah protokol IP 47 dan ESP ialah protokol IP 50, kedua-duanya dipadankan melalui medan protokol dalam pengepala IP. Peraturan yang ditulis sebagai port TCP 47 tidak memadankan apa-apa, dan begitulah dasar PPTP kelihatan betul tetapi masih menggugurkan setiap paket selepas jabat tangan.

Penghala pengguna menyembunyikan perkara ini di sebalik kotak semak laluan yang memasang peraturan protokol dan, untuk GRE, pembantu NAT yang diperlukan untuk memetakan aliran. Pada firewall sebenar anda menambah protokol itu sendiri: benarkan protokol IP 47 ke pelayan PPTP, benarkan protokol IP 50 ke get laluan IPsec. Di mana platform tidak menawarkan medan protokol, enkapsulasi ialah jalan keluar, sebab itulah IKEv2 boleh berundur ke UDP 4500 dan sebab itulah OpenVPN serta WireGuard tidak pernah menemui masalah ini.

Periksa apa yang sebenarnya dipadankan oleh peraturan sebelum menyalahkan klien. Kaunter paket yang kekal sifar pada get laluan bermaksud peraturan itu tidak pernah dicetuskan, dan berapa kali pun dipasang semula di sebelah klien, ia tidak berubah.

Arah, keadaan dan NAT mengubah jawapannya

Klien yang mendail keluar dan get laluan yang mendengar ke dalam ialah keperluan berbeza, dan senarai port yang sama boleh betul pada satu arah dan salah pada arah yang lain. Firewall berkeadaan menjejaki aliran UDP pada 500 dan 4500 dan membenarkan balasan kembali tanpa peraturan kedua. ESP dan GRE tidak membawa port, jadi peranti NAT tiada tempat berpaut dan memerlukan pembantu atau enkapsulasi untuk mengikut sesi.

Lintasan NAT ialah bahagian yang selalu terlepas pandang. IKEv2 bermula pada UDP 500, mengesan peranti NAT dan meneruskan pada UDP 4500, jadi dasar yang hanya membenarkan 500 memberi terowong yang terbentuk lalu senyap. L2TP/IPsec membuat gerakan yang sama. Jika tangkapan anda menunjukkan pertukaran pertama tetapi bukan trafik berterusan, cari peraturan yang berhenti pada 500.

Catat arah pada setiap peraturan. «Benarkan UDP 4500» tidak bermakna apa-apa sehingga anda menyebut dari mana ke mana, dan peraturan yang betul untuk klien berkeliling biasanya salah untuk rakan tapak-ke-tapak.

Periksa setiap laluan dengan tangkapan

Jalankan tangkapan pada get laluan, bukan pada klien: klien hanya merekod apa yang tiba. Penapis ini merangkumi keluarga di atas dan menunjukkan peringkat mana yang hilang:

sudo tcpdump -ni any tcp port 1723
sudo tcpdump -ni any udp port 500 or udp port 4500
sudo tcpdump -ni any proto gre
sudo tcpdump -ni any proto 50

Baca keluaran sebagai urutan. Apabila rundingan muncul tetapi protokol muatan tidak, pengguguran berlaku di suatu tempat antara klien dan get laluan. Apabila kedua-duanya muncul dan halaman masih gagal, firewall bukan lagi suspek; lihat penghalaan, DNS atau kumpulan alamat yang diberikan kepada klien.

Pada mesin tanpa tcpdump, bukti yang sama datang daripada kaunter antara muka dan peraturan. Bait masuk tetapi tidak keluar pada antara muka terowong menunjuk laluan balik, bukan peraturan kebenaran awal.

Tinggalkan set peraturan yang boleh anda pertahankan

SSTP pada TCP 443 tidak dapat dibezakan daripada HTTPS biasa oleh mana-mana penapis berasaskan port, dan itulah tujuannya apabila rangkaian hanya membenarkan trafik web. Itulah juga sebabnya peraturan 443 harus menamakan get laluan sebagai destinasi dan bukan seluruh internet. Padam peraturan sementara apa-sahaja-ke-apa-sahaja sebaik sahaja terowong berfungsi. Tulis peraturan mana yang dipadankan, nombor protokol jika ada, dan arahnya, supaya orang seterusnya bermula dengan bukti.

Get laluan awan titik-ke-tapak menjadikan pilihan itu kelihatan: profil yang dimuat turun menggunakan sama ada SSTP pada 443 atau IKEv2 pada 500 dan 4500, dan anda patut membuka hanya yang benar-benar dipilih oleh profil. PPTP tidak berbaloi dengan pengecualian GRE pada rangkaian moden, kerana pengendali mudah alih sering menggugurkan protokol 47 tanpa mengira firewall anda. Sebelum menutup tiket, pastikan peraturan sepadan dengan port dalam konfigurasi pelayan, medan protokol ditetapkan di tempat keluarga itu memerlukannya, dan destinasi ialah get laluan bukan sebarang alamat.