Menerbitkan server rumah lewat VPS saat CGNAT memblokir port

Saya mulai dari luar, seperti yang akan dilakukan pengguna: mengetik nama di peramban ponsel pada data seluler dan melihat koneksi menggantung sampai waktu habis. Nama itu ter-resolve, jadi DNS baik. Halaman penerusan port router rumah juga jalan buntu, karena alamat WAN-nya menunjukkan 100.64.31.42, dan itu bukan alamat yang akan dirutekan penyedia kepada saya dari internet. Angka itu menjelaskan seluruh kegagalan: saluran berada di belakang carrier-grade NAT, jadi alamat publik di sisi saya dari terowongan milik penyedia. Berikut adalah jalur yang saya tempuh dari tab yang menggantung itu sampai ke layanan yang menjawab.

Mulai dari klien dan bergerak ke dalam

Sebelum mengubah aturan apa pun, buktikan di mana rantai berhenti. Di laptop saya menjalankan dig +short files.example.net dan mendapat alamat VPS kembali, yang menyingkirkan DNS usang di mesin saya. Lalu curl -v --connect-timeout 5 files.example.net:5022 kehabisan waktu alih-alih ditolak. Perbedaan ini penting: habis waktu biasanya berarti paket dibuang di jalan, sementara penolakan berarti ada yang menjawab dan berkata tidak.

Langkah berikutnya ke dalam adalah VPS itu sendiri. ss -ltnp tidak menunjukkan apa pun yang mendengarkan di 5022, seperti yang diharapkan sebelum aturan DNAT ada. Di mesin yang sama wg show (atau ip -br a show tun0 untuk OpenVPN) mengonfirmasi bahwa peer rumah hidup dan punya handshake baru. Jika peer mati, tidak ada aturan NAT yang membantu, dan lampu hijau di halaman VPN router rumah tidak berarti apa-apa.

Pastikan saluran rumah benar-benar di belakang CGNAT

Bandingkan alamat yang dilaporkan router pada antarmuka WAN dengan yang dilihat layanan luar. Apa pun di 100.64.0.0/10, yaitu 100.64.x.x sampai 100.127.x.x, adalah rentang alamat bersama dari RFC 6598 dan tidak dapat dijangkau dari internet. Anda sampai pada kesimpulan yang sama ketika router mengklaim alamat privat biasa sementara pencarian publik mengembalikan sesuatu yang tidak terkait. Saluran CGNAT juga bisa datang dengan alamat publik yang hanya bertahan sampai lease berikutnya, sehingga penerusan port tampak bekerja satu jam lalu mati diam-diam.

Beberapa penyedia memang memberikan alamat publik sungguhan tetapi memblokir port masuk 80 dan 443 pada akun residensial. Jika layanan Anda hanya web dan alamat WAN benar-benar publik, tanyakan ke dukungan sebelum membangun relay. Jika tidak, desain di bawah berlaku sama untuk setiap port, dan ada baiknya menghentikan eksperimen di sisi router: penerjemah di jaringan penyedia mengakhiri koneksi sebelum mencapai antarmuka WAN Anda.

Arahkan nama ke alamat VPS

DNS tidak meneruskan lalu lintas, jadi catatan A untuk layanan harus memuat alamat publik VPS. Catatan A ke 192.168.1.20 hanya ter-resolve berguna bagi klien yang sudah di dalam VPN; dari internet catatan itu ter-resolve ke alamat yang tidak bisa dirutekan siapa pun. Untuk akses administratif VPS itu sendiri saya menyimpan nama terpisah, agar tidak pernah tertukar host mana yang dirujuk sebuah catatan.

Jika VPS dan mesin rumah sama-sama menyajikan HTTP, beri masing-masing namanya sendiri dan biarkan VPS memutuskan siapa yang menjawab. Melipat keduanya menjadi satu nama dan berharap proxy memilih backend yang tepat adalah tepat cara Anda menghabiskan sepanjang sore men-debug host yang salah.

DNAT satu port, biarkan SSH di 22

Opsi langsung adalah NAT tujuan di VPS. Aktifkan forwarding untuk kernel yang berjalan dan pertahankan alamat terowongan server rumah dalam aturan, 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 di 22 dan teruskan port lain, misalnya 5022, ke mesin rumah. Jika Anda meneruskan 22 ke mesin yang mati, Anda kehilangan satu-satunya jalur yang bisa memperbaikinya. Logika yang sama berlaku untuk proxy: jauhkan port manajemen VPS dari aturan relay.

Buat aturan itu permanen begitu berfungsi. Di Debian atau Ubuntu, apt install iptables-persistent lalu netfilter-persistent save menuliskannya ke /etc/iptables/rules.v4. Pada host dengan firewalld padanannya adalah penerusan port permanen pada zona, yang memerlukan firewall-cmd --reload sebelum berlaku. Aturan yang hanya hidup di memori hilang pada reboot pemeliharaan pertama dari penyedia, biasanya pada jam yang buruk.

Perbaiki jalur balik, atau hindari kebutuhannya

DNAT hanya menulis ulang tujuan. Server rumah melihat koneksi dari alamat klien asli, dan jika rute default-nya menunjuk ke router rumah, balasan keluar lewat WAN rumah tempat penerjemah penyedia membuangnya. Asimetri itulah kegagalan kedua yang saya temui, setelah aturan DNAT tampak sepenuhnya benar.

Dua perbaikan berhasil. Beri mesin rumah rute kebijakan agar lalu lintas dari terowongan kembali lewat terowongan:

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

Atau biarkan VPS menulis ulang sumbernya agar balasan punya alamat yang bisa dijangkau, dan biarkan conntrack membalikkannya saat 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 sebenarnya dari server rumah, jadi log aplikasi menampilkan 10.8.0.1 sebagai peer. Teruskan alamat asli di lapisan aplikasi, atau terima hilangnya pencatatan per klien, tetapi putuskan dengan sadar alih-alih menemukannya saat insiden.

Periksa seluruh jalur dari luar

Verifikasi dari jaringan yang bukan VPS dan bukan rumah: ponsel pada data seluler, atau shell murah di tempat lain. nc -vz files.example.net 5022 seharusnya melaporkan koneksi berhasil, dan openssl s_client -connect files.example.net:443 -servername files.example.net seharusnya menampilkan sertifikat untuk nama publik. Lalu periksa security group atau firewall cloud penyedia. Aturan DNAT yang tidak pernah melihat paket biasanya diblokir satu lapis di atas host.

Terakhir, putuskan apa yang terjadi saat terowongan putus. Aturan DNAT terus menerima koneksi dan diam-diam mengalirkannya ke terowongan mati, yang terlihat persis seperti layanan rusak. Pemeriksaan kesehatan di VPS yang menolak port selama peer mati hanya butuh beberapa baris dan menghemat satu jam dugaan. Setelah itu berhentilah menyunting aturan dan amati selama sehari sebelum mempercayainya.