Klien VPN dengan alamat LAN bukan berada di LAN
Memberi alamat LAN kepada klien VPN tidak meletakkannya pada pautan itu. Hos tempatan bertanya tentang jiran, jadi gateway mesti menjawab, jika tidak jawapan tidak pernah tiba.
Klien menyambung, menerima 10.50.0.200 dan tidak dapat mencapai pelayan di 10.50.0.20 walaupun kedua-dua nombor berada dalam /24 yang sama. Kepercayaan di sebalik konfigurasi itu ialah alamat daripada awalan LAN menjadikan klien sebahagian daripada LAN. Ia tidak. Klien berada pada pautan titik-ke-titik, pelayan menganggap destinasi itu tempatan, dan bahagian yang hilang ialah jawapan jiran yang tiada siapa hantar.
Mitos: awalan sama bermakna segmen sama
Awalan alamat memberitahu hos destinasi mana yang boleh dicapai secara langsung dan mana yang memerlukan penghala. Ia tidak memberitahu hos bagaimana destinasi itu disambung secara fizikal, dan ia sama sekali tidak menjamin destinasi boleh menjawab permintaan pada lapisan pautan. Itu soalan berbeza, yang dijawab oleh jadual berbeza pada hos. Topeng menjawab yang pertama dan jadual jiran menjawab yang kedua, dan hanya yang pertama berada dalam kawalan anda dari sisi VPN.
Apabila pelayan menghantar ke 10.50.0.200, ia membandingkan destinasi dengan topengnya sendiri, memutuskan alamat itu on-link, dan bertanya kepada segmen tempatan alamat perkakasan yang memilikinya. Permintaan itu keluar melalui antara muka Ethernet, dan klien VPN tiada di sana untuk mendengarnya.
Tiada apa-apa dalam konfigurasi klien boleh membetulkannya dari sisinya. Laluan balasan bergantung pada peranti di LAN yang menjawab bagi pihak klien, atau pada klien mempunyai alamat yang pelayan tidak anggap tempatan.
Apa yang hos tempatan sebenarnya lakukan dengan alamat itu
Tingkah laku itu mudah diperhatikan dan wajar diperhatikan sebelum anda mengubah apa-apa. Lihat jadual jiran pada hos LAN selepas ia cuba mencapai klien: entri tidak lengkap atau gagal ialah keseluruhan diagnosis dalam satu baris. Baris itu juga memberitahu anda bahawa kerosakan itu tempatan kepada segmen dan bukan di suatu tempat dalam terowong.
ip neigh show 10.50.0.200 ip route get 10.50.0.200 arping -I eth0 -c 3 10.50.0.200
Carian laluan akan melaporkan destinasi sebagai on-link melalui antara muka Ethernet, dan itulah masalahnya. Jika entri jiran kekal tidak lengkap semasa sesi VPN hidup, anda telah mengesahkan bahawa bahagian yang hilang ialah penyelesaian lapisan pautan, bukan penghalaan atau dasar firewall.
Jalankan pemeriksaan yang sama dari hos dalam subnet lain dan bandingkan. Hos yang mencapai klien melalui penghala tidak memerlukan entri jiran sama sekali, dan perbezaan itulah keputusan reka bentuk dalam skala kecil.
Bagaimana proxy ARP menyediakan lompatan seterusnya
proxy ARP membuat gateway menjawab permintaan lapisan pautan bagi pihak destinasi yang boleh dicapainya melalui antara muka lain. Hos LAN menerima alamat perkakasan, menghantar bingkai ke gateway, dan gateway memajukan paket ke dalam sesi VPN. Dari sudut pandangan hos, klien kelihatan berada di belakang gateway. Tiada apa-apa dalam konfigurasi klien berubah.
Dokumentasi ARP RouterOS MikroTik menerangkan penggunaan itu untuk klien dial-in yang meminjam ruang alamat LAN yang disambungkan. Mekanisme itu ialah pembaikan penyelesaian jiran, dan ia berfungsi kerana gateway benar-benar berada pada kedua-dua laluan.
Itu tidak sama dengan menjambatani klien ke dalam LAN. Gateway masih perlu memajukan paket ke sesi aktif yang betul, dan penghalaan serta dasar firewallnya masih perlu membenarkan perkhidmatan itu. proxy ARP mengubah siapa yang menjawab permintaan jiran, bukan siapa yang dibenarkan bercakap.
Baca nama mod platform dengan teliti. RouterOS memisahkan proxy-arp daripada local-proxy-arp, dan yang kedua mengendalikan trafik yang masuk dan keluar melalui antara muka yang sama. Itu bukan ejaan yang boleh ditukar ganti, dan mengaktifkan kedua-duanya tanpa diskriminasi bukan jalan pintas.
Apa yang proxy ARP tidak berikan kepada anda
Ia tidak menyediakan penemuan broadcast atau multicast. Klien yang perlu mencari perkhidmatan melalui broadcast masih akan gagal, kerana gateway memajukan unicast ke sesi dan tidak menjadikan klien ahli domain broadcast LAN. Protokol penemuan yang bergantung pada broadcast ialah sumber biasa laporan bahawa ia berfungsi untuk satu perkara dan bukan yang lain dalam reka bentuk alamat pinjaman.
Ia tidak menempah alamat itu. Jika nombor pinjaman juga berada dalam kumpulan DHCP atau penugasan statik, dua peranti boleh berakhir dengan alamat yang sama dan tingkah laku yang terhasil bergantung pada masa. Log masuk yang berjaya bukan tempahan.
Dan ia tidak menghapuskan keperluan untuk menyelaras dengan pemilik LAN. Entri proxy ARP yang mengejutkan pemilik pelan alamat ialah insiden sokongan yang menunggu minggu yang tenang.
Perbandingan dengan kumpulan yang dihalakan secara berasingan
Alternatifnya ialah memberi klien VPN awalan mereka sendiri dan membiarkan hos LAN menghala ke sana. Pelayan kemudian menghantar balasan off-link kepada gatewaynya, gateway menghalakan awalan ke titik akhir VPN, dan tiada penyelesaian jiran diperlukan sama sekali pada segmen LAN. Itu lebih sedikit bahagian bergerak daripada alamat pinjaman ditambah balasan proxy.
Reka bentuk itu lebih mudah difikirkan dan lebih mudah diaudit, kerana julat klien jelas berasingan daripada julat LAN. Ia memerlukan satu laluan, satu laluan balik dan satu peraturan akses, iaitu perkara yang sama yang diperlukan oleh reka bentuk proxy ARP di tempat yang kurang jelas.
Pilih antara model itu dengan sengaja dan bukan secara kebetulan. proxy ARP membaiki satu hubungan tertentu; kumpulan yang dihalakan mengelakkan keperluan pembaikan itu. Tuliskan yang mana anda pilih dan mengapa, dan orang seterusnya tidak perlu menemuinya semula daripada entri jiran yang gagal.