VPN istemcileri sunucuya ulaşıyor ama LAN'a ulaşmıyor: hangi düzeltme?

İstemci OpenVPN sunucusunun tünel adresine ping atıp yanıt alıyor, ardından sunucunun LAN'ındaki bir konağı deniyor ve hiçbir şey alamıyor. Bu ayrım arızayı epeyce daraltıyor: tünel ayakta, yönlendirme büyük olasılıkla çalışıyor ve yanıt geri dönmeyen bir kapıdan çıkıyor. Üç düzeltme var ve doğrusu neyi kontrol ettiğinize ve neden vazgeçmeye razı olduğunuza bağlı. Aşağıdaki üç soruyu sırayla yanıtlayın, seçim artık bir zevk meselesi olmaktan çıkar.

Önce hangi yönün bozuk olduğunu doğrulayın

İstek, VPN havuzundan gelen bir kaynak adresle tünel arabirimine varır. Sunucu onu LAN'daki konağa iletir ve o konak kendi tablosunun adlandırdığı ağ geçidine, genellikle LAN yönlendiricisine yanıt verir. Yönlendiricinin havuza rotası yoksa yanıt orada ölür ya da internete doğru sürüklenir.

Herhangi birini değiştirmeden önce iki makineyi de test edin. Sunucuda yönlendirme tablosuna bir istemciye nasıl ulaşacağını sorun; LAN'daki konağa aynı adrese nasıl ulaşacağını sorun. İlk arama genellikle tüneli, ikincisi LAN yönlendiricisini gösterir ve bu fark tek satırda arızadır. İki arama bir güvenlik duvarı denetiminden daha ucuzdur ve sorunun yönünü belirler.

ip route get 10.8.0.37
sysctl -n net.ipv4.ip_forward

LAN'daki konak zaten VPN sunucusunu gösteriyorsa sorununuz bir güvenlik duvarı kuralı ya da MTU sınırıdır, eksik bir dönüş yolu değil. Bir süzgeci onarmak için rota eklemeyin.

Birinci soru: uzak LAN'ın yönlendiricisini düzenleyebilir misiniz?

LAN yönlendiricisi sizinse temiz yanıt, VPN havuzuna VPN sunucusunun LAN adresini sonraki atlama olarak veren statik bir rotadır. İstemcilerin kaynak adreslerini bozmadan korur; bu, LAN konakları adrese göre günlük tuttuğunda, süzgeçlediğinde ya da hız sınırladığında önemlidir. Sunucuda çeviri de gerektirmez, böylece tünel saf bir yönlendirme yolu olarak kalır. Yarattığı yükümlülük belgelemedir, çünkü havuz, rota ve sunucu yapılandırması birbirini tutmalıdır.

Havuzu biri değiştirdiği gün sessizce çöker. Değeri bir kez yazın ve üç yerden herhangi birindeki düzenlemeyi üçünün düzenlemesi sayın.

Hizmeti barındıran NAS ya da Layer 3 anahtar aynı rotaya ihtiyaç duyar, her şeyi o rotaya sahip bir yönlendirici üzerinden göndermiyorsa. Alt ağı sonlandıran aygıtı denetleyin, yalnızca internete bakanı değil. Küçük ağlarda yönlendirme hakkında fikri olan üç aygıt sık görülür.

İkinci soru: LAN istemci adreslerini görmeyi bırakabilir mi?

Yönlendirici başkasınınsa, VPN sunucusunda çeviri yapmak işbirliği gerektirmez. LAN'daki konak sunucunun LAN adresini görür, ona yanıt verir ve sunucu geri çevirir. Cihazların ve NAT tabanlı uzaktan erişim rollerinin böyle davranmasının nedeni budur.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Bedeli atıf olmaktır: istemci başına adresler LAN günlüklerinden kaybolur. LAN'daki konaktaki her izin listesi o zaman havuz yerine sunucuyu adlandırmalıdır.

Çeviriyi işbirliği yokken seçin, sadece zahmetli olduğunda değil. İstemciyi gelecekteki her incelemeden saklar, hangi dizüstünün bağlantı açtığını bilmeniz gerekenler de dahil. Adresleri yüke gömen protokolleri de bozabilir, çünkü çeviri başlıkta yaşar. Hiçbir seçenek daha ileri değil; ikisi de sahiplik hakkında farklı soruları yanıtlar.

Üçüncü soru: sunucunun kendisi başka bir tünelin istemcisi mi?

Öteki topolojiyi düşünün: VPN sunucusu ayrıca ticari bir sağlayıcıyı arıyor, yani iki tüneli ve iki adres kümesi var. Kendi istemcileri için ilettiği trafik sağlayıcıdan çıkıyor ve sağlayıcı yanıtları havuz adreslerine geri yönlendirmez. İki tünel de sağlıklı olsa da yanıtların yok olmasının nedeni budur.

Düzeltme, giden tüneli de maskelemektir; böylece sağlayıcı yalnızca sunucunun tünel adresini görür. Ters yönün kendi kuralı gerekir, çünkü sunucunun kendi istemcilerinden birine bağlantı başlatması başka bir akıştır. O kural olmadan istemci yönlendiremediği bir adrese yanıt verir. Dar kuralı her geniş maskelemeden önce koyun ki özel çeviri kazansın.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tun1 -j MASQUERADE
iptables -t nat -A POSTROUTING -d 10.8.0.0/24 -o tun0 -j SNAT --to-source 10.8.0.1

Birden çok arabirimli konaklar istemci tarafından aynı görünen ilgili bir arıza ekler. Yanıt, kaynak adres başka bir tablodan seçildiği için daha düşük metriğe sahip arabirimden çıkar. Dönüş yolunu bir aramayla denetleyin, gidiş yolunun onu içerdiğini varsaymayın.

Sonra iki yönü ve iki boyutu doğrulayın

Değişiklikten sonra istemciden LAN'daki bir konağa, sonra LAN'daki konaktan istemciye ping atın. İkinci yön insanların atladığı yöndür ve eksik çeviri kuralını ortaya çıkaran da odur. İki sonucu zaman damgasıyla kaydedin ki sonraki bir gerileme karşılaştırılabilir olsun.

Sonra gerçek veriyi taşıyın, çünkü küçük bir ping geçerken büyük bir aktarımın tıkanması MTU belirtisidir. Bu arıza, rotayı düzelttiğiniz için kendinizi tebrik ettikten hemen sonra ortaya çıkar.

Son olarak, yeniden başlatmadan sonra tekrar test edin. Çalışma zamanındaki rota ve güvenlik duvarı komutları bunu atlatmaz ve sonraki açılışta kaybolan bir düzeltmeyi daha az bağlamı olan biri yeniden teşhis eder. Değişikliği sisteminizin zaten yaptığı biçimde kalıcı yapın, sonra bir kez bilerek yeniden başlatın.