Klien VPN sampai ke server tetapi tidak ke LAN: perbaikan mana?

Klien melakukan ping ke alamat tunnel server OpenVPN dan mendapat jawaban, lalu mencoba host di LAN server dan tidak mendapat apa pun. Pemisahan itu menyempitkan gangguan dengan cukup jelas: tunnel sudah naik, penerusan kemungkinan bekerja, dan balasannya keluar lewat pintu yang tidak mengarah kembali. Ada tiga perbaikan, dan yang tepat bergantung pada apa yang Anda kendalikan dan apa yang bersedia Anda lepaskan. Jawab tiga pertanyaan di bawah secara berurutan dan pilihan itu berhenti menjadi soal selera.

Pertama, pastikan arah mana yang rusak

Permintaan tiba di antarmuka tunnel dengan alamat sumber dari kumpulan VPN. Server meneruskannya ke host di LAN, dan host itu menjawab gateway yang disebut tabelnya sendiri, biasanya router LAN. Jika router tidak punya rute ke kumpulan itu, balasannya mati di sana atau mengembara ke arah internet.

Uji kedua mesin sebelum mengubah salah satunya. Tanyakan tabel routing di server bagaimana ia akan mencapai klien; tanyakan host di LAN bagaimana ia akan mencapai alamat yang sama. Pencarian pertama biasanya menunjuk tunnel dan yang kedua menunjuk router LAN, dan perbedaan itulah gangguannya dalam satu baris. Dua pencarian lebih murah daripada audit firewall dan keduanya menetapkan arah masalah.

ip route get 10.8.0.37
sysctl -n net.ipv4.ip_forward

Jika host di LAN sudah menunjuk server VPN, masalah Anda adalah aturan firewall atau batas MTU, bukan jalur balik yang hilang. Jangan menambahkan rute untuk memperbaiki filter.

Pertanyaan satu: bisakah Anda mengedit router LAN jauh itu?

Ketika router LAN itu milik Anda, jawaban bersihnya adalah rute statis ke kumpulan VPN dengan alamat LAN server VPN sebagai lompatan berikutnya. Rute ini menjaga alamat sumber klien tetap utuh, yang penting ketika host di LAN mencatat, memfilter, atau membatasi laju berdasarkan alamat. Rute ini juga tidak memerlukan penerjemahan di server, sehingga tunnel tetap menjadi jalur routing murni. Kewajiban yang dibuatnya adalah dokumentasi, karena kumpulan, rute, dan konfigurasi server harus sama.

Rute itu gagal diam-diam pada hari seseorang mengubah kumpulan. Tulis nilainya sekali dan perlakukan suntingan di salah satu dari tiga tempat sebagai suntingan pada ketiganya.

NAS atau switch Layer 3 yang menghosting layanan memerlukan rute yang sama, kecuali ia mengirim semuanya melalui router yang memilikinya. Periksa perangkat yang mengakhiri subnet, bukan hanya yang menghadap internet. Jaringan kecil sering punya tiga perangkat yang berpendapat soal routing.

Pertanyaan dua: bisakah LAN berhenti melihat alamat klien?

Ketika router itu milik orang lain, penerjemahan di server VPN tidak memerlukan kerja sama. Host di LAN melihat alamat LAN server, menjawabnya, dan server menerjemahkan kembali. Itulah sebabnya perangkat dan peran akses jarak jauh berbasis NAT berperilaku begitu.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Biayanya adalah atribusi: alamat per klien hilang dari log LAN. Daftar izin apa pun di host LAN kemudian harus menyebut server alih-alih kumpulan.

Pilih penerjemahan ketika kerja sama tidak tersedia, bukan ketika hanya tidak nyaman. Ia menyembunyikan klien dari setiap penyelidikan berikutnya, termasuk yang mengharuskan Anda tahu laptop mana yang membuka koneksi. Ia juga bisa merusak protokol yang menyematkan alamat di muatan, karena penerjemahan hidup di header. Tidak ada opsi yang lebih maju; keduanya menjawab pertanyaan berbeda tentang kepemilikan.

Pertanyaan tiga: apakah server sendiri klien dari tunnel lain?

Bayangkan topologi yang lain: server VPN juga men-dial penyedia komersial, jadi ia punya dua tunnel dan dua set alamat. Lalu lintas yang diteruskannya untuk kliennya sendiri keluar lewat penyedia itu, dan penyedia tidak akan merutekan balasan kembali ke alamat kumpulan. Itulah sebabnya balasan menghilang meskipun kedua tunnel sehat.

Perbaikannya adalah memaskerade tunnel keluar juga, agar penyedia hanya melihat alamat tunnel server. Arah sebaliknya memerlukan aturannya sendiri, karena server yang memulai koneksi ke salah satu kliennya sendiri adalah aliran yang berbeda. Tanpa aturan itu klien menjawab alamat yang tidak bisa ia rutekan. Letakkan aturan sempit sebelum masquerade lebar mana pun agar penerjemahan spesifik menang.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tun1 -j MASQUERADE
iptables -t nat -A POSTROUTING -d 10.8.0.0/24 -o tun0 -j SNAT --to-source 10.8.0.1

Host dengan banyak antarmuka menambahkan gangguan serupa yang terlihat identik dari sisi klien. Balasan keluar lewat antarmuka dengan metrik lebih rendah karena alamat sumber dipilih dari tabel lain. Periksa jalur balik dengan pencarian alih-alih menganggap jalur pergi menyiratkannya.

Lalu verifikasi kedua arah dan kedua ukuran

Setelah perubahan, ping dari klien ke host di LAN lalu dari host di LAN ke klien. Arah kedua itulah yang orang lewati, dan itulah yang membuka aturan penerjemahan yang tidak lengkap. Catat kedua hasil dengan cap waktu agar regresi berikutnya bisa dibandingkan.

Lalu pindahkan data sungguhan, karena ping kecil yang berhasil sementara transfer besar mandek adalah gejala MTU. Gangguan itu muncul tepat setelah Anda memberi selamat pada diri sendiri karena memperbaiki rute.

Terakhir, uji ulang setelah reboot. Perintah rute dan firewall saat berjalan tidak bertahan melewatinya, dan perbaikan yang hilang pada boot berikutnya akan didiagnosis lagi oleh orang dengan konteks lebih sedikit. Jadikan perubahan itu persisten dengan cara yang sudah dilakukan sistem Anda, lalu reboot sekali dengan sengaja.