Mengapa server di balik klien VPN membalas lewat terowongan

Koneksi masuk ke host yang juga menjalankan klien VPN gagal dengan cara yang sangat khas: handshake tiba, daemon menjawab, dan klien tidak menerima apa pun kembali. Tidak ada yang memblokir port. Jawaban keluar melalui terowongan, karena terowongan memiliki rute default dan kernel merutekan balasan berdasarkan tujuan, bukan berdasarkan ingatan tentang asal permintaan. Daemon baik-baik saja dan port terbuka.

Balasan dirutekan, bukan diingat

Klien VPN yang memasang rute default menambahkan entri yang mengalahkan gateway LAN, entah lewat metrik atau dengan membagi ruang menjadi dua separuh yang lebih spesifik. Paket keluar kini memilih antarmuka terowongan. Kernel tidak pernah bertanya dari mana paket yang dibalas itu semula datang. Satu kelalaian itulah yang menjelaskan setiap gejala berikut.

Arah maju dirutekan berdasarkan tujuan, begitu pula arah balik. Balasan dialamatkan ke klien publik, yang akan dibawa terowongan dengan senang hati. Ujung jauh menerima paket yang sumbernya bukan miliknya, membuangnya, dan klien asli menunggu sampai waktunya habis.

Penyaringan jalur balik yang ketat dapat menjatuhkan paket masuk sebelum daemon sempat membacanya. Periksa penghitung itu lebih dulu, karena jatuhnya filter dan kesalahan perutean tampak sama dari luar.

ip route show default
sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.eth0.rp_filter
nft list ruleset | grep -A3 'hook forward'

Perintah pertama menunjukkan rute default mana yang menang saat ini. Perintah kedua melaporkan apakah penyaringan ketat berlaku global atau per antarmuka, dan perintah ketiga menunjukkan aturan rantai penerusan yang mungkin terlibat.

Tiga cara mempertahankan jalur kembali

Mengecualikan tujuan layanan dari terowongan adalah pilihan tersempit. Rute host yang diarahkan ke gateway LAN, plus daemon yang terikat ke alamat fisik alih-alih semua alamat, menjaga satu aliran itu di luar terowongan. Perubahannya lokal dan mudah dibalik.

Perutean kebijakan adalah jawaban umum. Aturan yang dikunci pada alamat sumber atau pada tanda firewall memilih tabel yang rute defaultnya mengarah ke gateway WAN, sementara koneksi host itu sendiri tetap memakai terowongan. Pertahankan prioritas secara eksplisit agar aturan tidak tertutup nanti.

ip rule add from 203.0.113.25/32 table 100 priority 100
ip route add default via 192.0.2.1 dev eth0 table 100
ip route get 198.51.100.7 from 203.0.113.25

Dua perintah pertama membangun jalur alternatif untuk balasan yang bersumber dari alamat publik. Perintah ketiga menanyakan kernel jalur mana yang akan diambil oleh sumber dan tujuan persis itu, dan begitulah Anda memastikan aturan tersebut berpengaruh.

Penerjemahan sumber adalah opsi ketiga dan satu-satunya yang bertahan di depan router yang sudah melakukan NAT di depan layanan. Balasan harus kembali ke router itu, dan penyamaran ke antarmuka WAN mencapainya sambil menyembunyikan klien dari log layanan. Mengganti rute default secara manual setelah terhubung adalah diagnostik, karena klien menulis ulang tabel pada penyambungan ulang berikutnya.

Saat kotak itu juga merutekan untuk LAN

Kegagalan yang sama muncul satu lompatan lebih jauh saat host merutekan untuk perangkat di belakangnya. Koneksi masuk diteruskan ke perangkat internal yang satu-satunya jalur kembali adalah terowongan, dan balasan mencapai klien eksternal dari alamat penyedia. Perangkat internal bekerja dengan benar sepanjang waktu.

Pelacakan koneksi lalu melihat balasan untuk aliran yang tidak pernah dicatatnya dan membuangnya. Penerjemahan tujuan mengantarkan koneksi masuk ke perangkat, dan penerjemahan sumber membuat balasan tampak berasal dari router itu sendiri.

Rute kebijakan yang menahan port yang diteruskan di WAN sementara lalu lintas router sendiri memakai terowongan adalah padanan yang lebih rapi. Tanpa penerjemahan sumber balasan dialamatkan ke klien eksternal, dan perangkat internal tidak punya rute sama sekali untuk alamat itu.

Tiga penyelidikan yang memisahkan penyebab

Jalankan tiga penyelidikan: koneksi ke kotak dari internet, koneksi keluar darinya ke host publik, dan pencarian nama. Saat dua yang pertama tidak sepakat, jalur kembali yang bersalah. Saat nama gagal di kedua arah, resolver adalah kesalahan lain yang hanya berbagi terowongan.

Perbaiki dulu soal perutean, lalu lihat nama. Mencampur keduanya adalah cara server yang berfungsi disalahkan atas resolver yang rusak.

Catat antarmuka mana yang disebut pengecualian dan simpan konfigurasi di bawah kendali versi. Aturan yang ditulis terhadap antarmuka yang diganti nama setelah peningkatan lolos hari ini dan gagal setelah reboot berikutnya.