Mengapa host LAN mengirim ARP untuk alamat klien OpenVPN

Masalah keterjangkauan antara host LAN dan klien VPN sering kembali ke rencana alamat itu sendiri. Beri host itu antarmuka pada 10.0.100.0/22 dan ia akan memperlakukan setiap alamat dari 10.0.100.0 sampai 10.0.103.255 sebagai tersambung langsung, termasuk kumpulan klien yang diam-diam ditempatkan di 10.0.101.0/24. Balasan tidak pernah menuju router, karena dari sudut pandang host tidak ada router yang terlibat. Paket dialamatkan ke tetangga dan diminta di kabel.

Mekanisme itu berada di balik seluruh keluarga laporan: terowongan aktif, server punya rute, tetapi host LAN tetap tidak dapat menjangkau klien.

Prefiks /22 yang menelan /24

Baca prefiks sebagai rentang, bukan sebagai string. Sebuah /22 memuat 1024 alamat, dan 10.0.100.0/22 membentang dari 10.0.100.0 sampai 10.0.103.255, jadi kumpulan di 10.0.101.0/24 berada sepenuhnya di dalamnya. Kesalahan ini lolos peninjauan karena oktet pertama kumpulan tampak berbeda dari oktet pertama LAN, dan hanya oktet ketiga yang mengungkap pencakupan itu. Tuliskan kedua rentang dalam angka sebelum menyatakannya terpisah.

Pencakupan yang sama dapat muncul terbalik. Kumpulan yang tampak kosong karena belum ada yang memakainya tetap bisa jatuh di dalam prefiks yang diumumkan suatu router situs, dan rencana alamat adalah satu-satunya dokumen yang menunjukkannya.

Sambungan langsung berarti ARP, bukan perutean

Ketika host dengan antarmuka /22 mengirim ke 10.0.101.25, kernel membandingkan tujuan dengan prefiks antarmuka dan menemukan kecocokan. Paket menjadi pencarian tetangga alih-alih paket yang dirutekan, dan di Ethernet pencarian tetangga adalah permintaan ARP untuk alamat itu. Jika alamat itu milik klien VPN di balik gateway yang dirutekan, tidak ada host di LAN yang memilikinya, sehingga permintaan tetap tanpa jawaban dan paket dibuang. Terowongan tidak bersalah, dan klien tidak pernah melihat lalu lintasnya.

Itulah sebabnya kegagalan tampak asimetris dan kadang-kadang terputus-putus. Host VPN sering dapat menjangkau LAN karena rutenya sendiri menunjuk arah yang benar, sedangkan host LAN tidak dapat menjawab, dan apa pun yang menyimpan entri ARP lama akan membuat gejala berkedip.

TUN, TAP, dan apa yang dibawa masing-masing

Perangkat TUN membawa paket IP, dan perangkat TAP membawa bingkai Ethernet. Tautan TUN yang dirutekan tidak perlu membawa ARP untuk memberikan keterjangkauan IP, dan itulah sebabnya permintaan tanpa jawaban di atas memang diharapkan, bukan rusak. TAP dengan jembatan yang disengaja dapat memperluas domain siaran dan membuat ARP bekerja, tetapi mengubah apa yang dapat dilihat klien, menuntut titik akhir yang mendukung pembingkaian sama, dan merupakan perancangan ulang model jaringan, bukan perbaikan untuk prefiks yang tumpang tindih. Mengubah penerapan yang dirutekan menjadi TAP untuk menyembuhkan kesalahan rencana alamat menukar masalah kecil dengan masalah yang lebih besar.

Catat di mana permintaan ARP muncul dan sistem mana yang mengirimnya sebelum menarik kesimpulan. Pengirim memberi tahu Anda apa yang diyakininya tentang tujuan, bukan apa yang dilakukan terowongan.

Rancang kumpulan yang tidak dapat tumpang tindih

Pilih kumpulan di luar setiap prefiks tersambung dan setiap prefiks situs yang diumumkan, lalu tambahkan rute yang membuatnya terjangkau di kedua arah. Rentang seperti 10.8.0.0/24 di bagian rencana yang tidak terpakai mudah dipikirkan, dan LAN yang perlu menjangkaunya mendapat rute statis yang menunjuk ke server VPN. Ubah alokasi, rute yang diumumkan, alamat sumber yang diizinkan, dan aturan firewall secara bersamaan, karena semuanya menggambarkan satu rancangan, bukan empat pengaturan.

Source NAT di server dapat menyembunyikan kumpulan di balik alamat yang dapat dirutekan dari LAN, dan itu alat migrasi yang sah. Itu juga menulis ulang sumber, sehingga LAN kehilangan kemampuan mengaitkan sambungan ke klien individual dan menerapkan aturan per klien.

Untuk penerimaan, gunakan alamat yang benar-benar diberikan kepada klien nyata dan permintaan aplikasi nyata dari host LAN, lalu pastikan balasan mengikuti gateway yang direncanakan, bukan kabel.