Alamat L2TP itu IPCP, bukan sewa DHCP di LAN

Alamat dalam berasal dari negosiasi PPP, bukan dari server DHCP kantor. Lihat tahap mana yang memberikannya, mengapa LAN tidak bisa membalas, dan apa yang harus diperiksa.

Koneksi menyala dan adaptor menampilkan alamat dalam rentang kantor, jadi kesimpulan alaminya adalah VPN memberi Anda alamat LAN dan karenanya menempatkan Anda di LAN. Tak satu pun dari kedua bagian itu sepenuhnya benar. L2TP membawa sesi PPP, dan PPP menegosiasikan alamat IPv4 dalam melalui IPCP. Alamat itu adalah parameter sesi yang disepakati antara dua pihak, bukan sewa yang diberikan server DHCP kantor, dan memilikinya tidak menjadikan Anda tetangga di kabel kantor.

Dua alamat dalam satu koneksi

Ada dua negosiasi independen dalam koneksi L2TP. Yang luar membangun jalur terlindungi antara perangkat Anda dan endpoint VPN melalui jaringan apa pun yang sudah Anda miliki. Yang dalam adalah sesi PPP, dan di sanalah alamat sesi Anda dan alamat pihak lawan disepakati. Lalu lintas internet bisa keluar sepenuhnya di bawah alamat ketiga, alamat publik endpoint, itulah sebabnya halaman pemeriksaan VPN dan alamat adaptor jarang cocok.

Memisahkan ketiga peran itu menjawab sebagian besar pertanyaan yang orang bawa ke lapisan ini. Nomor privat pada antarmuka VPN itu normal dan memang diharapkan. Itu tidak mengatakan apa pun tentang apakah endpoint mengubah jalur keluar publik Anda, dan tidak dengan sendirinya menentukan tujuan mana yang dicapai lalu lintas Anda.

Apa tepatnya yang dilakukan IPCP

IPCP adalah protokol kendali IPv4 untuk PPP. Masing-masing pihak mengirim pesan Configure-Request yang menjelaskan opsi yang diinginkan, dan opsi alamat adalah salah satunya. Klien yang belum punya alamat biasanya meminta dengan 0.0.0.0, dan server membalas dengan Configure-Nak yang membawa alamat yang diinginkan untuk dipakai klien. Klien lalu meminta alamat itu, dan sesi menyala dengan alamat lokal dan alamat jarak jauh.

Pertukaran itu didokumentasikan dalam spesifikasi PPP dan IPCP, dan menjelaskan detail yang tampak seperti bug: alamat dipilih server menurut kebijakannya sendiri, yang bisa berupa kumpulan, pengaturan per pengguna, atau alamat yang terikat pada identitas yang terautentikasi. Ketika kumpulan habis, atau kebijakan bertentangan dengan permintaan, autentikasi bisa berhasil sementara negosiasi alamat gagal, dan klien melaporkan koneksi yang tidak pernah stabil.

ip addr show ppp0
ip route show default
dmesg | grep -i pppd

Baris log pppd yang menyebut alamat lokal dan alamat jarak jauh adalah akhir yang berhasil dari negosiasi itu. Ketiadaannya, di samping autentikasi yang berhasil, menunjuk ke tahap alamat, bukan ke kredensial.

Mengapa LAN tidak bisa membalas Anda

Alamat dari rentang sisi jauh menciptakan harapan bahwa host di LAN itu dapat menjangkau Anda, dan umumnya tidak bisa kecuali server merutekan alamat sesi Anda kembali ke terowongan. Berada di dalam kumpulan adalah pernyataan tentang alokasi, bukan tentang topologi. Server berkas kantor tidak punya rute ke alamat sesi Anda kecuali server VPN meneruskannya, dan itu pun mungkin tidak diizinkan.

Itu juga sebabnya rentang yang tumpang tindih menimbulkan masalah yang tidak sebanding dengan ukuran tampaknya. Jika kumpulan tumpang tindih dengan LAN yang sudah dipakai klien, tabel rute klien sekarang punya dua klaim atas prefiks yang sama, dan yang salah sering menang karena alasan yang tidak ada hubungannya dengan terowongan.

Periksa sesi, lalu rute

Periksa antarmuka dulu, lalu rute, lalu satu tujuan yang penting. Setiap langkah punya mode kegagalannya sendiri, dan menguji ketiganya sekaligus menghasilkan kesimpulan yang tidak bisa Anda pertahankan nanti.

curl -sS --max-time 5 https://ifconfig.me
ping -c 3 10.50.30.20
ip route get 10.50.30.20

Jika pemeriksaan publik menunjukkan alamat endpoint sementara tujuan privat kehabisan waktu, terowongan membawa rute default Anda dan sisi jauh tidak menjawab untuk tujuan itu. Jika tujuan privat menjawab tetapi pemeriksaan publik tidak berubah, profil memakai terowongan terpisah dan hanya sebagian lalu lintas memakai sesi.

Pisahkan ketiga tahap

Autentikasi, negosiasi alamat, dan penerusan gagal dengan cara berbeda, dan masing-masing punya pemilik berbeda. Kredensial adalah masalah identitas, habisnya IPCP adalah masalah kebijakan server, dan rute balik yang hilang adalah masalah desain jaringan. Melaporkan ketiganya sebagai “VPN rusak” menjamin perbaikan yang lambat.

Catat alamat yang diberikan, kumpulan asalnya, dan apakah LAN seharusnya menjangkaunya. Satu catatan itu mencegah orang berikutnya menganggap ada sewa DHCP dan mencari cakupan yang tidak pernah terlibat.

Artikel terkait