Server VPN rumahan tidak terjangkau: telusuri rantai NAT

Server menjawab di LAN, aturan penerusan port tampak benar, tetapi klien luar tetap tidak bisa terhubung. Menelusuri satu batas setiap kali ke arah luar lebih cepat daripada menyunting aturan untuk keempat kalinya, karena setiap batas meninggalkan buktinya sendiri: halaman WAN router, penerjemahan penyedia, dan pendengar di host. Mulailah dari halaman admin yang sudah terbuka dan akhiri dengan uji dari jaringan yang tidak Anda kendalikan. Catat setiap hasil sambil berjalan, karena urutannya adalah diagnosis dan angka yang diingat bukanlah bukti. Jika Anda hanya perlu terowongan keluar, penerjemahan bukan masalah Anda: hanya lalu lintas masuk yang tidak diminta yang diblokir.

Mulailah dari halaman WAN router

Masuk ke router dan baca halaman status, bukan daftar penerusan port. Catat alamat WAN, antarmuka tempatnya berada, dan apakah jenis koneksinya DHCP, PPPoE, atau sesuatu yang disediakan penyedia. Lalu bandingkan alamat itu dengan yang dilaporkan layanan eksternal, memakai ponsel dengan data seluler agar pengamatan tidak kembali melalui router yang sama. Kedua angka menjawab pertanyaan berbeda, dan membandingkannya adalah seluruh inti langkah ini.

Alamat WAN yang berbeda dari alamat publik yang diamati berarti ada setidaknya satu penerjemah di atas router. Itu belum merupakan kesalahan, karena banyak penyedia menerjemahkan secara desain dan layanan tetap bekerja. Jika keduanya cocok, router kemungkinan memiliki alamat itu dan masalahnya berpindah ke dalam jaringan Anda. Bagaimanapun, catat pasangan itu beserta tanggalnya, karena penyedia menetapkan ulang alamat dan perbandingan dengan catatan bulan lalu tidak ada gunanya.

Naik satu hop ke atas

Jalankan traceroute dari router itu sendiri dan baca beberapa hop pertama. Alamat publik yang berulang, hop pertama yang menjawab dengan alamat privat, atau alamat di dalam rentang bersama 100.64.0.0/10 semuanya menunjuk ke penerjemah di hulu. RFC 6598 mendefinisikan rentang itu justru untuk penerapan seperti ini, karena itu melihatnya di kolom WAN adalah sinyal kuat, bukan keanehan. Dua penerjemah di jalur membuat jejaknya kurang jelas, jadi bacalah polanya, bukan satu baris.

Sebagian penyedia hanya menampilkan alamat yang diberikan di portal pelanggan, jadi lihatlah ke sana sebelum menyimpulkan router berbohong. Alamat di portal yang cocok dengan pengamatan luar Anda sementara router melaporkan hal lain adalah bukti paling jelas adanya penerjemah di hulu. Simpan kedua halaman dalam catatan perubahan, karena perdebatan tentang siapa pemilik batas mana jauh lebih cepat dengan dua gambar bertanggal.

Pastikan pendengar dan penerusan

Uji di LAN membuktikan layanan bekerja secara lokal dan tidak membuktikan apa pun tentang keterjangkauan dari luar. Banyak router menjawab aturan penerusannya sendiri dari dalam, sehingga uji jepit rambut berhasil sementara jalur luar masih tertutup. Pastikan daemon terikat pada alamat dan port yang Anda anggap, lalu uji dari luar. Semua yang di bawah ini hanya untuk dibaca.

ss -lunp | grep -E '1194|51820'
ip -4 addr show | grep -E 'inet '
curl -s --max-time 5 ifconfig.me
traceroute -n -m 5 1.1.1.1

Jika uji luar menunjukkan tidak ada paket yang tiba di router, penurunan terjadi di hulu dan tidak ada aturan lokal yang akan memperbaikinya. Jika paket tiba dan tidak ada yang menjawab, batas berikutnya adalah pendengar atau firewall host. Penangkapan paket di host menentukan mana dari keduanya yang Anda lihat, dan itu lebih cepat daripada satu putaran lagi menebak aturan. Biarkan pendengar dan transportnya tidak berubah selama membandingkan, atau uji berikutnya akan menjawab pertanyaan lain.

Ubah topologi, bukan aturan yang sama

Ketika penerjemah milik penyedia, perbaikannya adalah jalur lain, bukan penerusan lain. VPS kecil dengan alamat publik, disambungkan terowongan keluar dari sisi rumah, menempatkan titik akhir yang terjangkau di depan layanan. Alamat publik yang diberikan penyedia lebih sederhana di tempat yang tersedia dan biasanya lebih murah daripada menjalankan mesin. IPv6 menghapus penerjemahan sepenuhnya, asalkan jaringan klien, catatan DNS, dan kebijakan firewall semuanya mendukung.

DNS dinamis hanya memperbarui nama; ia tidak menciptakan keterjangkauan, dan mengarahkannya ke alamat bersama mengirim klien ke gerbang penyedia yang juga dipakai pelanggan lain. Kegagalan itu tampak persis seperti server mati, karena itulah catatan dari langkah sebelumnya penting. Catat ke alamat mana nama itu diselesaikan saat uji gagal, dan simpan jawabannya bersama hasil uji.

Tulis ulang rencana di sekitar batas yang Anda kendalikan: pendengar, terowongan, dan rute. Pertahankan penerusan lama hanya selama masih menggambarkan sesuatu yang benar, karena aturan yang tidak lagi cocok dengan topologi lebih buruk daripada tidak ada aturan. Catat lapisan mana yang sebenarnya memblokir dan bukti apa yang menunjukkannya. Jika tidak, orang berikutnya yang membuka halaman admin akan mengulangi setiap langkah penelusuran ini dari awal.