Klien VPN dengan alamat LAN bukan berada di LAN

Klien terhubung, menerima 10.50.0.200, dan tidak dapat menjangkau server di 10.50.0.20 meskipun kedua nomor berada di /24 yang sama. Keyakinan di balik konfigurasi itu adalah bahwa alamat dari prefiks LAN menjadikan klien bagian dari LAN. Tidak. Klien berada di tautan titik-ke-titik, server menganggap tujuan itu lokal, dan bagian yang hilang adalah jawaban tetangga yang tidak dikirim siapa pun.

Mitos: prefiks sama berarti segmen sama

Prefiks alamat memberi tahu host tujuan mana yang dapat dijangkau langsung dan mana yang memerlukan router. Itu tidak memberi tahu host bagaimana tujuan terpasang secara fisik, dan sama sekali tidak menjamin bahwa tujuan dapat menjawab permintaan pada lapisan tautan. Itu pertanyaan berbeda, yang dijawab oleh tabel berbeda pada host. Masker menjawab yang pertama dan tabel tetangga menjawab yang kedua, dan hanya yang pertama berada dalam kendali Anda dari sisi VPN.

Ketika server mengirim ke 10.50.0.200, ia membandingkan tujuan dengan masker miliknya, memutuskan bahwa alamat itu on-link, dan menanyakan alamat perangkat keras pemiliknya kepada segmen lokal. Permintaan itu keluar melalui antarmuka Ethernet, dan klien VPN tidak ada di sana untuk mendengarnya.

Tidak ada apa pun dalam konfigurasi klien yang dapat memperbaikinya dari sisinya. Jalur jawaban bergantung pada perangkat di LAN yang menjawab atas nama klien, atau pada klien memiliki alamat yang tidak dianggap lokal oleh server.

Apa yang sebenarnya dilakukan host lokal dengan alamat itu

Perilakunya mudah diamati dan layak diamati sebelum Anda mengubah apa pun. Lihat tabel tetangga pada host LAN setelah ia mencoba menjangkau klien: entri tidak lengkap atau gagal adalah seluruh diagnosis dalam satu baris. Baris itu juga memberi tahu Anda bahwa kesalahan bersifat lokal pada segmen dan bukan di suatu tempat di dalam terowongan.

ip neigh show 10.50.0.200
ip route get 10.50.0.200
arping -I eth0 -c 3 10.50.0.200

Pencarian rute akan melaporkan tujuan sebagai on-link melalui antarmuka Ethernet, dan itulah tepatnya masalahnya. Jika entri tetangga tetap tidak lengkap selama sesi VPN aktif, Anda telah memastikan bahwa bagian yang hilang adalah resolusi lapisan tautan, bukan perutean atau kebijakan firewall.

Jalankan pemeriksaan yang sama dari host di subnet lain dan bandingkan. Host yang menjangkau klien melalui router sama sekali tidak memerlukan entri tetangga, dan perbedaan itulah keputusan desain dalam ukuran kecil.

Bagaimana proxy ARP menyediakan hop berikutnya

Proxy ARP membuat gateway menjawab permintaan lapisan tautan atas nama tujuan yang dapat dijangkau melalui antarmuka lain. Host LAN menerima alamat perangkat keras, mengirim frame ke gateway, dan gateway meneruskan paket ke sesi VPN. Dari sudut pandang host, klien tampak berada di belakang gateway. Tidak ada yang berubah dalam konfigurasi klien.

Dokumentasi ARP RouterOS dari MikroTik menjelaskan penggunaan itu untuk klien dial-in yang meminjam ruang alamat LAN yang terhubung. Mekanismenya adalah perbaikan resolusi tetangga, dan berhasil karena gateway benar-benar berada di kedua jalur.

Itu tidak sama dengan menjembatani klien ke dalam LAN. Gateway tetap harus meneruskan paket ke sesi aktif yang benar, dan perutean serta kebijakan firewall-nya tetap harus mengizinkan layanan. Proxy ARP mengubah siapa yang menjawab permintaan tetangga, bukan siapa yang boleh berbicara.

Baca nama mode platform dengan cermat. RouterOS memisahkan proxy-arp dari local-proxy-arp, dan yang kedua menangani lalu lintas yang masuk dan keluar melalui antarmuka yang sama. Keduanya bukan ejaan yang dapat dipertukarkan, dan mengaktifkan keduanya tanpa pembedaan bukan jalan pintas.

Apa yang tidak diberikan proxy ARP kepada Anda

Itu tidak menyediakan penemuan melalui broadcast atau multicast. Klien yang perlu menemukan layanan melalui broadcast tetap akan gagal, karena gateway meneruskan unicast ke sesi dan tidak menjadikan klien anggota domain broadcast LAN. Protokol penemuan yang bergantung pada broadcast merupakan sumber umum laporan bahwa itu berhasil untuk satu hal dan tidak untuk hal lain dalam desain alamat pinjaman.

Itu tidak memesan alamatnya. Jika nomor pinjaman juga berada di kumpulan DHCP atau penetapan statis, dua perangkat dapat berakhir dengan alamat yang sama dan perilaku yang dihasilkan bergantung pada waktu. Login yang berhasil bukanlah pemesanan.

Dan itu tidak menghilangkan kebutuhan untuk berkoordinasi dengan pemilik LAN. Entri proxy ARP yang mengejutkan pemilik rencana alamat adalah insiden dukungan yang menunggu minggu yang tenang.

Perbandingan dengan kumpulan yang dirutekan terpisah

Alternatifnya adalah memberi klien VPN prefiks mereka sendiri dan membiarkan host LAN merutekan ke sana. Server kemudian mengirim balasan off-link ke gateway-nya, gateway merutekan prefiks ke titik akhir VPN, dan tidak diperlukan resolusi tetangga sama sekali pada segmen LAN. Itu lebih sedikit bagian yang bergerak daripada alamat pinjaman ditambah jawaban proxy.

Desain itu lebih mudah dipikirkan dan lebih mudah diaudit, karena rentang klien terlihat terpisah dari rentang LAN. Itu memerlukan satu rute, satu jalur balik, dan satu aturan akses, hal-hal yang sama yang dibutuhkan desain proxy ARP di tempat yang kurang jelas.

Pilih di antara model-model itu dengan sengaja dan bukan kebetulan. Proxy ARP memperbaiki satu hubungan tertentu; kumpulan yang dirutekan menghindari kebutuhan akan perbaikan itu. Tuliskan mana yang Anda pilih dan mengapa, dan orang berikutnya tidak perlu menemukannya kembali dari entri tetangga yang gagal.