Lompatan berikutnya dalam rute VPN: mengapa gateway harus dapat dijangkau secara lokal

Rute ke jaringan VPN membawa dua alamat yang mudah tertukar: prefiks tujuan yang hendak dicapai paket dan lompatan berikutnya yang akan memindahkannya satu langkah lebih dekat. Pada host LAN, lompatan berikutnya itu harus berupa perute yang benar-benar dapat Anda jangkau pada tautan yang sama. Alamat VPN jarak jauh bukan lompatan berikutnya, sekencang apa pun ia cocok dengan tujuan yang ada di benak Anda.

Runbook ini mencakup kasus biasa: laptop di 192.168.20.0/24, gateway VPN dengan alamat LAN 192.168.20.5, dan jaringan jarak jauh 10.70.0.0/24 di belakang gateway itu. Semua perintah di bawah mengasumsikan Anda berada di laptop kecuali dinyatakan lain.

Dua alamat, satu rute

Entri yang dimaksud adalah 10.70.0.0/24 via 192.168.20.5. Prefiks mengatakan ke mana paket pergi; alamat via mengatakan siapa yang membawanya ke sana. Kernel menolak memasang rute yang gateway-nya tidak dapat ia jangkau melalui antarmuka yang Anda sebutkan, dan penolakan itulah intinya: lompatan berikutnya yang membutuhkan terowongan agar dapat dijangkau tidak bisa menjadi lompatan berikutnya yang membangun terowongan.

Jadi pemeriksaan pertama bukan «apakah gateway hidup» melainkan «apakah gateway ada di tautan ini». Subnet laptop itu sendiri, entri ARP atau tetangganya, dan antarmuka dalam rute harus semuanya sepakat. Alamat yang hanya ada di dalam 10.70.0.0/24 bisa menjadi tujuan rute kedua, tetapi tidak pernah menjadi via rute pertama.

Apa yang ditanggung gateway karena lompatan berikutnya

Memasang rute di laptop hanya menentukan serah-terima pertama. Setelah itu gateway membutuhkan jalurnya sendiri: penerusan diaktifkan, rute terowongan untuk 10.70.0.0/24, dan kebijakan akses apa pun yang mengatur siapa yang boleh memakainya. Di Linux itu net.ipv4.ip_forward=1 ditambah rute terowongan; tembok api di depannya membutuhkan aturan yang mengizinkan aliran yang diteruskan.

Arah kembali adalah bagian yang orang lupakan. Sisi jauh harus memiliki rute kembali ke 192.168.20.0/24, atau rancangannya harus menerjemahkan sumber laptop menjadi sesuatu yang dikenal sisi jauh. Ping yang berhasil dari gateway membuktikan gateway dapat mencapai jaringan jarak jauh; itu tidak mengatakan apa pun tentang apakah paket laptop bertahan dalam perjalanan pulang.

Periksa pencarian dari host yang mengirim

Tanyakan kepada kernel lompatan berikutnya mana yang akan ia pilih, dan bacalah antarmuka dalam jawabannya:

ip route get 10.70.0.10
ip route show 10.70.0.0/24
ip neigh show 192.168.20.5

Jika pencarian melaporkan gateway dan antarmuka LAN, bagian pertama terkonfigurasi sebagaimana dimaksud. Jika ia melaporkan perangkat terowongan, sesuatu yang lebih awal dalam tabel lebih spesifik dan menang. Jika rute sama sekali tidak mau dipasang, kernel memberi tahu Anda bahwa gateway tidak dapat dijangkau, dan pesan itu lebih berguna daripada tangkapan paket mana pun.

Lalu ulangi uji dari tempat yang benar. Permintaan yang dibuat di gateway memakai alamat sumber gateway itu sendiri, yang dapat menyembunyikan rute kembali yang hilang atau kebijakan yang hanya mengizinkan sumber tertentu. Manual ip-route memisahkan tujuan, gateway, dan penggantian onlink, dan penggantian itu layak dipahami sebelum Anda memakainya.

Jangan pakai onlink untuk memalsukan keterjangkauan

onlink memberi tahu kernel agar melewati pemeriksaan keterjangkauan sebuah gateway dan tetap mengirim ke sana. Ia tidak membuat jalur, tidak menyelesaikan ARP untuk alamat yang tidak ada, dan tidak membuat perute jarak jauh menjawab di segmen Ethernet Anda. Ia sah untuk gateway yang menjawab tetapi tidak berada di subnet tersambung, dan ia jebakan ketika dipakai untuk membungkam galat yang belum Anda jelaskan.

Jika rute hanya terpasang dengan onlink, pertanyaan berikutnya adalah mengapa gateway tidak berada di tempat yang Anda kira. VLAN yang salah, alamat kedua pada antarmuka yang salah, atau salah ketik pada oktet terakhir semuanya menghasilkan ini, dan masing-masingnya juga memutus jalur kembali begitu lalu lintas mulai mengalir.

Terowongan titik-ke-titik bukan Ethernet

Perangkat terowongan tidak melakukan ARP dan sering tidak memiliki subnet tetangga yang berarti. Rutenya sering tampak seperti 10.70.0.0/24 dev tun0, tanpa via sama sekali, karena rekan sejawat adalah satu-satunya ujung lain. Menyalin via bergaya LAN ke tabel itu menghasilkan rute yang mungkin ditolak kernel atau, lebih buruk, rute yang menunjuk alamat yang tidak pernah dijawab rekan sejawat.

Pisahkan kedua model dalam runbook: rute LAN punya gateway yang dapat dijangkau, rute terowongan punya antarmuka dan rekan sejawat. WireGuard, OpenVPN, dan IPsec semuanya menampilkan bentuk yang sedikit berbeda, jadi catat bentuk yang benar-benar Anda pakai alih-alih menggeneralisasi dari satu host.

Tambahkan, konfirmasi, kembalikan

Seluruh perubahan adalah tiga perintah dan satu pemeriksaan, dan sebaiknya dicatat dalam urutan itu:

sudo ip route add 10.70.0.0/24 via 192.168.20.5
ip route get 10.70.0.10
ping -c 3 10.70.0.10
sudo ip route del 10.70.0.0/24 via 192.168.20.5

Konfirmasi jalurnya, konfirmasi satu tujuan, lalu siapkan baris penghapusan untuk berjaga-jaga bila perubahan membuat host tidak terjangkau dengan cara yang tidak Anda duga. Jika rute harus bertahan setelah reboot, letakkan di konfigurasi jaringan host, bukan di profil shell, dan uji reboot sebelum Anda bergantung padanya. Rute yang hanya ada di shell yang menambahkannya adalah rute yang akan Anda debug dua kali.