Mengapa Pelayan VPN di Belakang CGNAT Tidak Pernah Menerima Sambungan

Alamat 100.64, nama DNS dinamik yang menyelesaikan di tempat lain dan tiada jabat tangan masuk ialah satu masalah: NAT pembawa. Sahkannya, kemudian hantar trafik keluar melalui geganti.

Penghala melaporkan alamat WAN yang bermula dengan 100.72, nama DNS dinamik menyelesaikan ke alamat awam yang lain, dan pelayan VPN pada penghala itu tidak pernah melengkapkan jabat tangan dari luar. Pengusulan port telah dikonfigurasikan, perkhidmatan berjalan, dan ujian dari LAN masih berfungsi. Tiada apa-apa dalam log penghala yang kelihatan seperti ralat. Gabungan itu ialah NAT gred pembawa, dan tiada peraturan tembok api boleh membuka port pada alamat yang dipegang oleh ISP.

Mengesahkan alamat kongsi mengambil masa dua minit dan mengelakkan seminggu perubahan konfigurasi.

Tanda-tanda yang menunjukkan NAT pembawa

Bandingkan alamat WAN pada halaman status penghala dengan alamat yang dilaporkan oleh carian luaran. Alamat WAN dalam 100.64.0.0/10 ialah tanda biasa, dan julat peribadi 10/8, 172.16/12 serta 192.168/16 bermaksud perkara yang sama. Jika traceroute menunjukkan hop awam yang sama berulang, atau hop awal menjawab dengan alamat peribadi, ada penterjemah lain antara penghala dan internet. Sesetengah ISP hanya menyenaraikan alamat yang diberikan dalam portal pelanggan, jadi eksport nilai itu bersama traceroute.

Menukar protokol atau port tidak membantu, kerana masalahnya ialah kebolehcapaian masuk dan bukan port tertutup.

Mengapa pengusulan dan DNS dinamik tidak dapat membetulkannya

Peraturan pengusulan port memetakan port pada antara muka WAN penghala, tetapi trafik masuk tidak pernah sampai ke antara muka itu: ISP menterjemahkannya dahulu dan hanya menghantar apa yang dibenarkan oleh jadualnya sendiri. Menerbitkan alamat kongsi dalam DNS dinamik mengarahkan klien ke get laluan ISP yang digunakan oleh ramai pelanggan, itulah sebabnya nama diselesaikan tetapi jabat tangan masih gagal. Ujian hairpin berjaya kerana penghala menjawab peraturannya sendiri dari dalam, dan UPnP mempunyai titik buta yang sama.

Mengkonfigurasi semula klien juga tidak akan membantu, kerana kegagalan berlaku sebelum mana-mana tetapan klien dibaca.

Geganti melalui VPS dengan laluan eksplisit

Letakkan alamat awam di hadapan dengan menyewa VPS terkecil yang mampu membawa trafik, kemudian buat penghala rumah mendail keluar ke arahnya. UDP keluar dari rangkaian rumah melepasi NAT pembawa, jadi terowong terbentuk dari dalam dan VPS menjadi titik akhir yang boleh dicapai. Bahagian rumah menjadi klien dengan alamat terowong tetap, bukan pelayan.

Pada VPS, tambahkan entri direktori khusus klien supaya pelayan tahu peer mana yang memiliki subnet rumah, dan tambahkan laluan kernel yang sepadan.

# /etc/openvpn/server/ccd/home-site.conf
ifconfig-push 10.8.0.10 255.255.255.0
iroute 192.168.50.0 255.255.255.0

# server.conf
client-config-dir /etc/openvpn/server/ccd
route 192.168.50.0 255.255.255.0
push "route 10.8.0.0 255.255.255.0"

Baris iroute memberitahu OpenVPN klien mana yang menerima trafik untuk subnet rumah; baris route meletakkan subnet itu dalam jadual kernel VPS supaya paket masuk ke dalam terowong. Untuk perkhidmatan yang diterbitkan, tambahkan peraturan NAT destinasi yang menghantar port awam ke 10.8.0.10 dan dayakan net.ipv4.ip_forward.

Uji laluan dari luar

Sahkan setiap hop di bahagian awam, kerana terowong yang berjaya tidak membuktikan perkhidmatan boleh dicapai. Keadaan mendengar dan tangkapan paket pada VPS memisahkan 'tiada apa yang tiba' daripada 'tiba lalu dibuang'.

ss -lunp | grep 1194
tcpdump -ni any udp port 1194
nft list ruleset | grep -A4 dnat

# from a phone on mobile data, not the home Wi-Fi
nc -vz -u 203.0.113.10 1194

Jika tangkapan menunjukkan paket dari telefon tetapi tiada balasan, perhentian seterusnya ialah konfigurasi pelayan atau tembok api. Jika tangkapan tidak menunjukkan apa-apa, klien masih menyelesaikan atau menghantar ke alamat yang salah.

Alternatif yang patut dinilai harganya dahulu

Alamat IPv4 khusus daripada ISP ialah penyelesaian terpendek dan biasanya bayaran bulanan kecil. IPv6 asli menghapuskan penterjemahan di kedua-dua hujung apabila VPN, rangkaian klien dan rekod DNS semuanya menyokongnya. Lapisan mesh dengan penghala subnet di dalam rangkaian rumah mencapai geganti yang sama tanpa VPS, tetapi dengan kos bergantung pada perkhidmatan penyelarasan.

Pilih geganti apabila keperluan ialah akses masuk yang stabil dan setiap peraturan harus kekal di bawah kawalan anda. Pilih alamat ISP apabila bajet mengizinkan dan matlamatnya sekadar berhenti memikirkannya.

Artikel berkaitan