Mengapa hos LAN menghantar ARP untuk alamat klien OpenVPN

Masalah kebolehcapaian antara hos LAN dan klien VPN sering kembali kepada pelan alamat itu sendiri. Berikan hos itu antara muka pada 10.0.100.0/22 dan ia akan menganggap setiap alamat dari 10.0.100.0 hingga 10.0.103.255 sebagai bersambung terus, termasuk kumpulan klien yang diletakkan secara senyap pada 10.0.101.0/24. Balasan tidak pernah pergi ke penghala, kerana dari sudut pandangan hos tiada penghala terlibat. Paket dialamatkan kepada jiran dan diminta pada wayar.

Mekanisme itu berada di sebalik seluruh keluarga laporan: terowong aktif, pelayan mempunyai laluan, namun hos LAN masih tidak dapat mencapai klien.

Awalan /22 yang menelan /24

Baca awalan sebagai julat, bukan sebagai rentetan. Satu /22 mengandungi 1024 alamat, dan 10.0.100.0/22 merentang dari 10.0.100.0 hingga 10.0.103.255, jadi kumpulan pada 10.0.101.0/24 terletak sepenuhnya di dalamnya. Kesilapan ini terlepas semakan kerana oktet pertama kumpulan kelihatan berbeza daripada oktet pertama LAN, dan hanya oktet ketiga mendedahkan liputan itu. Tulis kedua-dua julat dalam angka sebelum mengisytiharkannya berasingan.

Liputan yang sama boleh muncul secara terbalik. Kumpulan yang kelihatan kosong kerana belum ada yang menggunakannya masih boleh jatuh di dalam awalan yang diumumkan oleh sesuatu penghala tapak, dan pelan alamat ialah satu-satunya dokumen yang menunjukkannya.

Sambungan langsung bermaksud ARP, bukan penghalaan

Apabila hos dengan antara muka /22 menghantar ke 10.0.101.25, kernel membandingkan destinasi dengan awalan antara muka dan menemui padanan. Paket menjadi pencarian jiran dan bukannya paket dihalakan, dan pada Ethernet pencarian jiran ialah permintaan ARP untuk alamat itu. Jika alamat itu milik klien VPN di belakang get laluan yang dihalakan, tiada hos di LAN memilikinya, jadi permintaan kekal tanpa jawapan dan paket digugurkan. Terowong tidak bersalah, dan klien tidak pernah melihat trafik itu.

Itulah sebabnya kegagalan kelihatan tidak simetri dan kadangkala terputus-putus. Hos VPN sering dapat mencapai LAN kerana laluannya sendiri menunjuk arah yang betul, manakala hos LAN tidak dapat menjawab, dan apa-apa yang menyimpan entri ARP lama akan membuat gejala berkelip.

TUN, TAP dan apa yang dibawa oleh setiap satu

Peranti TUN membawa paket IP, dan peranti TAP membawa bingkai Ethernet. Pautan TUN yang dihalakan tidak perlu membawa ARP untuk menyediakan kebolehcapaian IP, dan itulah sebabnya permintaan tanpa jawapan di atas memang dijangka, bukan rosak. TAP dengan jambatan yang disengajakan boleh meluaskan domain siaran dan menjadikan ARP berfungsi, tetapi ia mengubah apa yang boleh dilihat klien, memerlukan titik akhir yang menyokong pembingkaian yang sama, dan merupakan reka bentuk semula model rangkaian dan bukannya pembaikan untuk awalan yang bertindih. Menukar penggunaan yang dihalakan kepada TAP untuk menyembuhkan kesilapan pelan alamat menukar masalah kecil dengan masalah yang lebih besar.

Catat di mana permintaan ARP muncul dan sistem mana yang menghantarnya sebelum membuat kesimpulan. Penghantar memberitahu anda apa yang diyakininya tentang destinasi, bukan apa yang dilakukan terowong.

Reka kumpulan yang tidak boleh bertindih

Pilih kumpulan di luar setiap awalan bersambung dan setiap awalan tapak yang diumumkan, kemudian tambah laluan yang menjadikannya boleh dicapai dalam kedua-dua arah. Julat seperti 10.8.0.0/24 dalam bahagian pelan yang tidak digunakan mudah difikirkan, dan LAN yang perlu mencapainya mendapat laluan statik yang menunjuk ke pelayan VPN. Ubah peruntukan, laluan yang diumumkan, alamat sumber yang dibenarkan dan peraturan tembok api secara serentak, kerana semuanya menggambarkan satu reka bentuk dan bukan empat tetapan.

Source NAT pada pelayan boleh menyembunyikan kumpulan di sebalik alamat yang boleh dihalakan dari LAN, dan itu alat migrasi yang sah. Ia juga menulis semula sumber, jadi LAN kehilangan keupayaan mengaitkan sambungan kepada klien individu dan menggunakan peraturan bagi setiap klien.

Untuk penerimaan, gunakan alamat yang benar-benar diberikan kepada klien sebenar dan permintaan aplikasi sebenar daripada hos LAN, kemudian sahkan bahawa balasan mengikut get laluan yang dirancang dan bukan wayar.