OpenVPN istemcileri birbirini görmüyor: subnet mi net30 mu?

Birbiriyle ilgisiz iki arıza aynı şikâyeti üretir. İlkinde bir istemci diğerine tünel adresiyle bile ulaşamaz, çünkü adresler aynı subnet içinde değildir ya da sunucu eşler arasındaki trafiği iletmez. İkincisinde ping çalışır ama uygulamanın cihaz listesi boş kalır, çünkü keşif, katman 3 tünelinin taşıyamadığı broadcast'a dayanır. Tek bir ping ikisini ayırır ve her birinin düzeltmesi diğerininkine hiç benzemez.

Tek bir ping sorunu ikiye böler

Bir istemciden diğerinin tünel adresine ping atın, adına değil ve LAN adresine değil. Başarısız olursa sorun iletim veya adreslemedir ve düzeltilene kadar keşif konu dışıdır. Başarılı olursa iletim zaten çalışıyor ve eksik olan broadcast veya ad çözümlemesidir.

ip addr show tun0

Her şeyden önce istemcinin arayüzünü okuyun, çünkü topolojiyi ağ maskesi adlandırır. /24 veya başka bir subnet maskesi paylaşılan havuz demektir; eş adresi olan /30 ise her istemcinin tam olarak bir komşusu olduğu, o da sunucu olan eski noktadan noktaya düzeni anlatır.

net30 ve subnet, istemci tarafından okunduğunda

net30'da sunucu her istemciye küçük bir blok verir, bu yüzden sunucu iletmedikçe başka bir istemcinin tünel adresine rota yoktur. subnet'te havuzun tamamı tek bir ağdır, her istemci herkese seslenebilir ve sunucu aralarında iletir. Bu yüzden bir sunucu yapılandırması sağlıklı görünürken eşler arası ping başarısız olabilir: hiçbir şey bozuk değildir, istemciler yalnızca aynı ağda değildir. İstemci çalışan bir bağlantı ve yanıt vermeyen bir eş adresi görür; bu güvenlik duvarı gibi okunur ama aslında bir adresleme düzenidir.

Yönergenin değiştirilmesi sunucu tarafında bir düzenleme ve yeniden başlatmadır, ve zaten açık oturumlar için değil bir sonraki bağlantı için geçerlidir. Değişikliği değerlendirmeden önce istemcileri yeniden bağlayın. Cihaz yapılandırmayı bir web arayüzünden yeniden üretiyorsa yönergeyi, dosyayı ve tarihi not edin, ve arayüz varken düzenlemeyi onun üzerinden yapın, çünkü yeniden derleme bir sonraki kaydetmede elle yapılan düzenlemenin üzerine yazar.

client-to-client ayrı bir kapıdır

Aynı subnet içinde bile sunucu, bir istemciden gelip başkasına adreslenen paketleri client-to-client ayarlı değilse atar. Bu anahtar sözcük sunucuyu yalnızca kabul eden bir uç nokta yerine eşler arası trafiğin ileticisi yapar. İnsanların topolojiyi düzelttikten sonra kaçırdığı ikinci koşul budur.

Bu broadcast'a uzanmaz. Ayar istemciler arasında unicast iletir; tüneli paylaşılan bir segmente dönüştürmez ve ne kadar ayarlanırsa ayarlansın multicast keşif sorgusunu her eşe ulaştırmaz.

TUN ve TAP, ve her biri neyi taşıyabilir

Bir tap aygıtını LAN'a köprülemek uzak istemcileri ofisin broadcast alanına sokar, bu da keşfi tamamen çözer. Bedeli TAP'ı uygulamayan platformlar, sunucuda var olması gereken bir köprü ve ofis kablosundaki broadcast fırtınasının her uzak dizüstü bilgisayara ulaştığı bir arıza alanıdır.

Ad çözümlemesine ihtiyaç duyan iki veya üç iş istasyonu için hosts girdisi veya unicast adres bir köprüden çok daha ucuzdur. Yerine koyamadığınız bir protokol katman 2 keşfine bağlı olduğunda TAP'a başvurun, daha önce değil.

Köprüsüz aynı subnet istemcileri

LAN aralığından adres vermek istemciyi kabloya koymaz. Sunucu tünel ile Ethernet arasında yönlendirme yapar, bu yüzden o adres için ARP sunucunun arayüzünde durur ve LAN'ın geri kalanı onun nerede yaşadığını asla öğrenmez.

ip neigh add proxy 10.50.1.250 dev eth0

Proxy ARP bu boşluğu sunucunun istemci adına yanıt vermesiyle kapatır. Bir aralık için parpd istemciler gelip giderken girdileri yönetir, sysctl net.ipv4.conf.eth0.proxy_arp=1 ise başka yere yönlendirilen her şeye yanıt verir, ki bu yoğun bir segmentte kendi sürprizlerini yaratacak kadar geniştir.

Hangi yolu seçerseniz seçin, NAT'ı tünel ile kablo arasından kaldırın. Bir MASQUERADE kuralı tam olarak yanıtlamaya çalıştığınız adresleme sorusunu gizler. Ayrıca sıradaki kişiye istemci tarafından akıl yürütemeyeceği bir topoloji bırakır.

Herhangi bir şeyi değiştirmeden önce sunucuda tcpdump -ni tun0 ile bir denemeyi yakalayın ve eş paketinin hiç gelip gelmediğini doğrulayın. Gelinip atılması client-to-client'a işaret eder; hiç gelmemesi topoloji veya yönlendirmeye. OpenVPN 2.6 kılavuzu iki anahtar sözcüğü ve varsayılan topolojiyi belgeler; bir forum gönderisinden satır kopyalamadan önce kendi sürümünüzle karşılaştırmaya değer.

• tun arayüzü /30 eş çifti yerine havuz maskesi gösterir.
• Keşfi test etmeden önce diğer tünel adresine doğrudan ping başarılı olur.
• Eşlerin paket alışverişi gerektiğinde sunucu yapılandırması client-to-client içerir.
• Uygulama başarısız diyor yerine test ettiğiniz keşif protokolünü adlandırın.
• TAP'ı yalnızca gruptaki her istemci platformu destekliyorsa kullanın.
• Aynı subnet içinde erişilebilirlik önemliyse NAT'ı tünel ile LAN arasındaki yoldan uzak tutun.