Menerbitkan pelayan rumah melalui VPS apabila CGNAT menyekat port

Saya bermula dari luar, seperti yang akan dilakukan pengguna: menaip nama dalam pelayar telefon pada data mudah alih dan melihat sambungan tergantung sehingga tamat masa. Nama itu diselesaikan, jadi DNS baik. Halaman pemajuan port penghala rumah juga jalan buntu, kerana alamat WAN-nya menunjukkan 100.64.31.42, dan itu bukan alamat yang akan dihalakan penyedia kepada saya dari internet. Nombor itu menerangkan seluruh kegagalan: talian berada di belakang carrier-grade NAT, jadi alamat awam di sebelah saya dalam terowong milik penyedia. Berikut ialah laluan yang saya tempuh dari tab yang tergantung itu sehingga ke perkhidmatan yang menjawab.

Mulakan dari klien dan bergerak ke dalam

Sebelum menukar apa-apa peraturan, buktikan di mana rantaian berhenti. Pada komputer riba saya menjalankan dig +short files.example.net dan mendapat alamat VPS semula, yang menyingkirkan DNS lapuk pada mesin saya. Kemudian curl -v --connect-timeout 5 files.example.net:5022 tamat masa dan bukannya ditolak. Perbezaan ini penting: tamat masa biasanya bermaksud paket digugurkan di jalan, manakala penolakan bermaksud sesuatu menjawab dan berkata tidak.

Langkah seterusnya ke dalam ialah VPS itu sendiri. ss -ltnp tidak menunjukkan apa-apa yang mendengar pada 5022, seperti yang dijangka sebelum peraturan DNAT wujud. Pada mesin yang sama wg show (atau ip -br a show tun0 untuk OpenVPN) mengesahkan bahawa peer rumah hidup dan mempunyai handshake baharu. Jika peer mati, tiada peraturan NAT yang membantu, dan lampu hijau pada halaman VPN penghala rumah tidak bermaksud apa-apa.

Pastikan talian rumah benar-benar di belakang CGNAT

Bandingkan alamat yang dilaporkan penghala pada antara muka WAN dengan apa yang dilihat perkhidmatan luar. Apa-apa dalam 100.64.0.0/10, iaitu 100.64.x.x hingga 100.127.x.x, ialah julat alamat kongsi daripada RFC 6598 dan tidak boleh dicapai dari internet. Anda sampai pada kesimpulan yang sama apabila penghala mendakwa mempunyai alamat peribadi biasa sementara carian awam mengembalikan sesuatu yang tidak berkaitan. Talian CGNAT juga boleh datang dengan alamat awam yang hanya bertahan sehingga lease seterusnya, jadi pemajuan port kelihatan berfungsi sejam kemudian mati senyap.

Sesetengah penyedia memang memberikan alamat awam sebenar tetapi menyekat port masuk 80 dan 443 pada akaun kediaman. Jika perkhidmatan anda hanya web dan alamat WAN benar-benar awam, tanyakan kepada sokongan sebelum membina relay. Jika tidak, reka bentuk di bawah terpakai sama untuk setiap port, dan eloklah hentikan eksperimen di sebelah penghala: penterjemah dalam rangkaian penyedia menamatkan sambungan sebelum ia sampai ke antara muka WAN anda.

Halakan nama ke alamat VPS

DNS tidak memajukan trafik, jadi rekod A bagi perkhidmatan mesti mengandungi alamat awam VPS. Rekod A ke 192.168.1.20 hanya diselesaikan dengan berguna untuk klien yang sudah berada dalam VPN; dari internet ia diselesaikan ke alamat yang tiada siapa boleh halakan. Untuk akses pentadbiran VPS itu sendiri saya menyimpan nama berasingan, supaya tidak pernah keliru host mana yang dirujuk oleh sesuatu rekod.

Jika VPS dan mesin rumah kedua-duanya menyajikan HTTP, beri setiap satu namanya sendiri dan biarkan VPS menentukan siapa yang menjawab. Melipat kedua-duanya menjadi satu nama dan berharap proksi memilih backend yang betul ialah tepat cara anda menghabiskan sepanjang petang menyahpepijat host yang salah.

DNAT satu port, biarkan SSH pada 22

Pilihan langsung ialah NAT destinasi pada VPS. Hidupkan forwarding untuk kernel yang berjalan dan kekalkan alamat terowong pelayan rumah dalam peraturan, bukan alamat LAN-nya:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A PREROUTING -p tcp -d 198.51.100.10 --dport 5022 -j DNAT --to-destination 10.8.0.2

Biarkan SSH ke VPS sendiri pada 22 dan majukan port lain, misalnya 5022, ke mesin rumah. Jika anda memajukan 22 ke mesin yang mati, anda kehilangan satu-satunya laluan yang boleh membaikinya. Logik yang sama terpakai pada proksi: jauhkan port pengurusan VPS daripada peraturan relay.

Jadikan peraturan itu kekal apabila ia berfungsi. Pada Debian atau Ubuntu, apt install iptables-persistent kemudian netfilter-persistent save menuliskannya ke /etc/iptables/rules.v4. Pada hos dengan firewalld padanannya ialah pemajuan port kekal pada zon, yang memerlukan firewall-cmd --reload sebelum berkuat kuasa. Peraturan yang hanya hidup dalam memori hilang pada but semula penyelenggaraan pertama daripada penyedia, biasanya pada waktu yang buruk.

Betulkan laluan balik, atau elakkan keperluannya

DNAT hanya menulis semula destinasi. Pelayan rumah melihat sambungan daripada alamat klien asal, dan jika laluan lalainya menunjuk ke penghala rumah, balasan keluar melalui WAN rumah tempat penterjemah penyedia menggugurkannya. Asimetri itulah kegagalan kedua yang saya temui, selepas peraturan DNAT kelihatan betul sepenuhnya.

Dua pembetulan berkesan. Beri mesin rumah laluan dasar supaya trafik dari terowong kembali melalui terowong:

ip rule add from 10.8.0.2 table 100
ip route add default dev wg0 table 100

Atau biarkan VPS menulis semula sumber supaya balasan mempunyai alamat yang boleh dicapainya, dan biarkan conntrack membalikkannya semasa keluar:

iptables -t nat -A POSTROUTING -d 10.8.0.2 -p tcp --dport 5022 -j SNAT --to-source 10.8.0.1

Versi SNAT menyembunyikan alamat klien sebenar daripada pelayan rumah, jadi log aplikasi memaparkan 10.8.0.1 sebagai peer. Sampaikan alamat asal pada lapisan aplikasi, atau terima kehilangan pengelogan setiap klien, tetapi putuskan dengan sedar daripada menemukannya semasa insiden.

Periksa seluruh laluan dari luar

Sahkan dari rangkaian yang bukan VPS dan bukan rumah: telefon pada data mudah alih, atau shell murah di tempat lain. nc -vz files.example.net 5022 sepatutnya melaporkan sambungan berjaya, dan openssl s_client -connect files.example.net:443 -servername files.example.net sepatutnya memaparkan sijil bagi nama awam. Kemudian periksa kumpulan keselamatan atau tembok api awan penyedia. Peraturan DNAT yang tidak pernah melihat paket biasanya disekat satu lapisan di atas hos.

Akhir sekali, putuskan apa yang berlaku apabila terowong jatuh. Peraturan DNAT terus menerima sambungan dan senyap-senyap menyalurkannya ke terowong mati, yang kelihatan tepat seperti perkhidmatan rosak. Pemeriksaan kesihatan pada VPS yang menolak port selagi peer mati hanya mengambil beberapa baris dan menjimatkan sejam tekaan. Selepas itu berhentilah menyunting peraturan dan perhatikan selama sehari sebelum mempercayainya.