Klien OpenVPN tidak saling melihat: subnet atau net30?
Klien mencapai server tetapi tidak satu sama lain. Pisahkan gangguan dengan satu ping, lalu pilih topologi subnet, client-to-client, atau segmen TAP yang dijembatani.
Dua gangguan yang tidak saling terkait menghasilkan keluhan yang sama. Pada yang pertama, satu klien tidak menjangkau klien lain bahkan lewat alamat tunnel, karena alamatnya tidak berada dalam satu subnet atau server tidak meneruskan lalu lintas antar-peer. Pada yang kedua, ping berfungsi dan daftar perangkat aplikasi tetap kosong, karena penemuan bergantung pada broadcast yang tidak dapat dibawa tunnel lapisan 3. Satu ping memisahkan keduanya, dan perbaikan untuk masing-masing sama sekali tidak mirip dengan perbaikan untuk yang lain.
Satu ping membelah masalah menjadi dua
Dari satu klien, ping alamat tunnel klien lain, bukan namanya dan bukan alamat LAN-nya. Jika gagal, penerusan atau pengalamatan adalah masalahnya dan penemuan tidak relevan sampai itu diperbaiki. Jika berhasil, penerusan sudah bekerja dan celah yang tersisa adalah broadcast atau resolusi nama.
ip addr show tun0
Baca antarmuka klien sebelum apa pun, karena netmask menamai topologinya. /24 atau mask subnet lain berarti kumpulan alamat bersama; /30 dengan alamat peer berarti tata letak titik-ke-titik lama, di mana setiap klien punya tepat satu tetangga, yaitu server.
net30 versus subnet, dibaca dari sisi klien
| What you observe | net30 | subnet |
|---|---|---|
| Client netmask | /30 with a peer address | The pool's own mask |
| Peers a client can address directly | One, the server | Every client in the pool |
| Addressing | One /30 block per client, with the server as the only peer | One pool mask shared by all clients |
| Effect of client-to-client | Required for any peer traffic | Required for peer traffic, still no broadcast |
Dengan net30 server membagikan blok kecil per klien, jadi rute ke alamat tunnel klien lain tidak ada kecuali server meneruskannya. Dengan subnet seluruh kumpulan alamat menjadi satu jaringan, setiap klien dapat menghubungi setiap klien lain, dan server meneruskan di antaranya. Itulah sebabnya satu konfigurasi server bisa tampak sehat sementara ping antar-peer gagal: tidak ada yang rusak, kliennya memang tidak berada dalam satu jaringan. Klien melihat tautan yang bekerja dan alamat peer yang tidak menjawab, yang terbaca seperti firewall tetapi sebenarnya tata letak pengalamatan.
Mengganti direktif adalah suntingan di sisi server plus mulai ulang, dan berlaku untuk koneksi berikutnya, bukan sesi yang sudah terbuka. Sambungkan ulang klien sebelum menilai perubahan. Jika perangkat membuat ulang konfigurasi dari antarmuka web, catat direktif, berkas, dan tanggalnya, lalu lakukan suntingan lewat antarmuka bila ada, karena pembangunan ulang akan menimpa suntingan manual pada penyimpanan berikutnya.
client-to-client adalah gerbang tersendiri
Bahkan di dalam satu subnet server membuang paket yang datang dari satu klien dan dialamatkan ke klien lain kecuali client-to-client diatur. Kata kunci itu menjadikan server penerus lalu lintas antar-peer, bukan titik akhir yang hanya menerimanya. Itu syarat kedua yang orang lewatkan setelah memperbaiki topologi.
Ini tidak meluas ke broadcast. Pengaturan ini meneruskan unicast antar-klien; ia tidak mengubah tunnel menjadi segmen bersama, dan berapa pun jumlahnya tidak akan mengantarkan kueri penemuan multicast ke setiap peer.
TUN versus TAP, dan apa yang dapat dibawa masing-masing
| Property | TUN | TAP |
|---|---|---|
| Layer | Layer 3, IP packets | Layer 2, Ethernet frames |
| Broadcast and multicast | Not carried | Carried |
| Bridging to the LAN | Not applicable | Required for a shared segment |
| Client platform support | Everywhere | Missing on Android and iOS, limited on macOS |
Menjembatani perangkat tap ke LAN menempatkan klien jarak jauh di domain broadcast kantor, yang menyelesaikan penemuan sepenuhnya. Harganya adalah platform yang tidak menerapkan TAP, jembatan yang harus ada di server, dan domain kegagalan tempat badai broadcast di kabel kantor mencapai setiap laptop jarak jauh.
Untuk dua atau tiga stasiun kerja yang membutuhkan resolusi nama, entri hosts atau alamat unicast jauh lebih murah daripada jembatan. Gunakan TAP ketika protokol yang tidak dapat Anda ganti bergantung pada penemuan lapisan 2, dan bukan sebelumnya.
Klien subnet yang sama tanpa jembatan
Memberi alamat dari rentang LAN tidak menempatkan klien di kabel. Server merutekan antara tunnel dan Ethernet, sehingga ARP untuk alamat itu berhenti di antarmuka server dan sisa LAN tidak pernah tahu di mana ia tinggal.
ip neigh add proxy 10.50.1.250 dev eth0
Proxy ARP menutup celah itu dengan membuat server menjawab atas nama klien. Untuk rentang, parpd mengelola entri saat klien datang dan pergi, sementara sysctl net.ipv4.conf.eth0.proxy_arp=1 menjawab untuk semua yang dirutekan ke tempat lain, yang cukup luas untuk menimbulkan kejutan sendiri di segmen yang sibuk.
Rute mana pun yang Anda pilih, buang NAT antara tunnel dan kabel. Aturan MASQUERADE menyembunyikan tepat pertanyaan pengalamatan yang ingin Anda jawab. Ia juga meninggalkan orang berikutnya dengan topologi yang tidak dapat ia nalar dari sisi klien.
Sebelum mengubah apa pun, tangkap satu percobaan di server dengan tcpdump -ni tun0 dan pastikan apakah paket peer benar-benar tiba. Tiba lalu dibuang menunjuk ke client-to-client; tidak pernah tiba menunjuk ke topologi atau perutean. Manual OpenVPN 2.6 mendokumentasikan kedua kata kunci dan topologi bawaan, yang layak dicocokkan dengan versi Anda sebelum menyalin baris dari kiriman forum.
- Antarmuka tun menunjukkan mask kumpulan alamat, bukan pasangan peer /30.
- Ping langsung ke alamat tunnel lain berhasil sebelum Anda menguji penemuan.
- Konfigurasi server menyertakan
client-to-clientsetiap kali peer harus bertukar paket. - Sebutkan protokol penemuan yang Anda uji alih-alih mengatakan aplikasinya gagal.
- Gunakan TAP hanya jika setiap platform klien dalam grup mendukungnya.
- Jauhkan NAT dari jalur antara tunnel dan LAN ketika keterjangkauan dalam subnet yang sama penting.