Klien VPN yang dirutekan mencapai server tetapi bukan host LAN

Tunnel naik, klien melakukan ping ke server VPN, dan sebuah share di mesin satu lompatan lebih jauh tidak pernah menjawab. Tidak ada apa pun di konfigurasi klien yang menjelaskannya, karena permintaan memang keluar dari klien dan memang tiba. Yang gagal adalah perjalanan pulang, dan perangkat yang gagal biasanya gateway LAN, bukan host VPN. Menelusuri paket balasan menjelaskan seluruh kelas gejala ini.

Ikuti Balasannya, Bukan Permintaannya

Server VPN mendekripsi paket klien dan meneruskannya ke LAN dengan alamat klien masih di kolom sumber. Host tujuan menjawab alamat itu, dan sekarang tabel ruteknya sendiri yang menentukan segalanya. Gateway bawaannya tidak tahu apa pun tentang kumpulan tunnel, sehingga balasan keluar menuju penyedia internet dan dibuang di suatu tempat sepanjang jalur itu.

Di klien gejalanya adalah timeout senyap: tanpa penolakan, tanpa reset, hanya tidak ada apa-apa. Penelusuran share menggantung, ping melaporkan tidak ada balasan, dan log server tampak sehat karena server sudah menjalankan tugasnya.

Letakkan Rute Balik di Tempat Host Melihat

Setiap host LAN menanyakan gateway bawaannya, jadi gateway adalah satu-satunya perangkat yang perlu tahu di mana kumpulan tunnel berada. Tambahkan rute statis di sana dan setiap host mewarisi jalur yang benar tanpa disentuh.

Jika gateway membagikan alamatnya sendiri sebagai opsi DHCP, sebarkan rute dengan cara itu agar mesin baru mengambilnya otomatis. Jika tidak, rute hidup di satu berkas konfigurasi dan hilang pada pembangunan ulang berikutnya.

# on the LAN gateway; tunnel pool 172.20.5.0/24, VPN server 10.60.4.10
ip route add 172.20.5.0/24 via 10.60.4.10
ip route get 172.20.5.14

Mengapa NAT Sumber Tampak Memperbaikinya

Menyamarkan kumpulan klien di belakang alamat server VPN menghapus masalahnya dengan menghapus alamat klien dari paket. Balasan lalu kembali ke server, yang sudah tahu cara mencapai tunnel, dan semuanya berjalan. Harganya adalah host internal tidak lagi bisa melihat siapa kliennya, dan setiap koneksi tampak berasal dari satu mesin.

Pertukaran itu kadang tepat, misalnya ketika perangkat vendor tidak bisa diberi rute statis. Buat aturannya tidak lebih lebar dari kumpulan saat ini, karena aturan yang ditulis untuk /24 berhenti cocok pada hari kumpulan dinomori ulang menjadi /16, dan tanda pertamanya adalah sekumpulan klien baru yang tersambung dan tidak mencapai apa pun.

iptables -t nat -A POSTROUTING -s 172.20.5.0/24 -o ens18 -j MASQUERADE
iptables -t nat -L POSTROUTING -n -v

Jalur Cloud Memerlukan Tiga Pengaturan

Di VPC celah yang sama kembali dalam bentuk lain, karena subnet tidak punya rute sama sekali untuk rentang klien. Tabel rute memerlukan entri untuk kumpulan tunnel yang menargetkan antarmuka jaringan instans, dan antarmuka itu harus mematikan pemeriksaan sumber dan tujuan agar platform menerima paket yang sumbernya bukan alamatnya sendiri. Grup keamanan dan ACL jaringan juga harus mengizinkan kumpulan itu di kedua arah.

Setiap kelalaian menghasilkan kegagalan sebagian yang berbeda. Lewatkan entri tabel rute dan instans privat menjawab ke subnet yang tidak dapat membawa balasan kembali ke kumpulan. Dengan pemeriksaan masih aktif, platform membuang balasan setelah instans sudah mengirimnya. Tanpa aturan grup keamanan, permintaannya sendiri tidak pernah tiba, dan klien melihat timeout satu lapis lebih awal.

Jalankan Pemeriksaan dalam Urutan Ini

Pastikan penerusan dan kebijakan penyaringan sebelum menyalahkan perutean, karena host yang tidak mau meneruskan gagal dengan cara senyap yang sama. Lalu baca pengaturan jalur balik yang berlaku pada antarmuka yang membawa tunnel, karena penyaring ketat dapat membuang balasan yang datang dari arah tak terduga.

Akhiri dengan tangkapan di host LAN saat klien melakukan ping ke sana. Permintaan yang tiba tanpa balasan yang cocok membuktikan jalur pulang, dan permintaan yang tidak pernah tiba memindahkan kesalahan kembali ke server atau tunnel.

sysctl net.ipv4.ip_forward net.ipv4.conf.all.rp_filter
tcpdump -ni any host 172.20.5.14 and icmp

Pemeriksaan sumber dan tujuan didokumentasikan di panduan antarmuka jaringan elastis. Aturlah pada antarmuka yang benar-benar membawa lalu lintas tunnel, bukan pada adaptor tak terkait yang terpasang pada instans yang sama.