OpenVPN istemcisi sunucuya ulaşıyor ama LAN ana makinelerine ulaşmıyor: kontrol listesi

Tünel ayakta ve sunucu yanıt veriyor, ama LAN ana makineleri sessiz. Paketi istemci rotasından dönüş yoluna kadar izleyin, sonra NAT veya statik bir rota seçin.

İstemci bağlı olduğunu söylüyor, tünel adresi ping'e yanıt veriyor ve ofis LAN'inde hiçbir şey yanıt vermiyor. Bunu neredeyse her istemci güncellemesinden sonra görüyorum ve ilk dürtü güvenlik duvarını açmak oluyor, ki bu genellikle yanlış adımdır: tünel sağlam ve kopma paketin geçmesi gereken üç atlamadan birinde. Yolu paketin izlediği sırayla yürüyün, önce istemci rotası, sonra sunucudaki yönlendirme, sonra dönüş yolculuğu, ve arızanın sahibini birkaç dakikada bulursunuz.

Birinci adım: istemcinin yönlendirme kararını izleyin

Sunucuya dokunmadan önce istemcinin paketi tünele gönderdiğini kanıtlayın. Tüm tabloyu okumak yerine çekirdeğe belirli bir LAN ana makinesi için hangi arayüzü kullanacağını sorun:

ip route get 192.168.50.10

Yanıt fiziksel bağdaştırıcınızı ve ofis ağ geçidini adlandırıyorsa sunucu tarafındaki hiçbir değişiklik yardımcı olamaz. OpenVPN rotaları yalnızca sunucu onları ittiğinde dağıtır, bu yüzden sunucu yapılandırmasında push "route 192.168.50.0 255.255.255.0" arayın ve ardından istemciyi yeniden bağlayın. Çoğu istemci itilen rotaları bağlanırken uygular, profili yeniden yüklediğinizde değil.

Windows'ta aynı sorunun başka bir komutu var. Find-NetRoute -RemoteIPAddress 192.168.50.10 yığının seçeceği arayüzü ve sonraki atlamayı yazdırır, route print -4 ise itilen önekin var olup olmadığını gösterir.

İkinci adım: sunucunun paketi ileteceğini doğrulayın

İstemci rotası doğruysa paket sunucuya ulaşır ve sunucu onu iletmeyi kabul etmelidir. Çekirdek anahtarı ilk kapıdır ve sysctl net.ipv4.ip_forward 1 döndürmelidir. echo 1 > /proc/sys/net/ipv4/ip_forward ile ayarlamak bir sonraki yeniden başlatmaya kadar çalışır ve aynı şikâyetin haftalar sonra geri dönmesinin nedeni tam olarak budur.

Bunu yeniden başlatmayı atlatan bir yere yazın:

echo 'net.ipv4.ip_forward = 1' > /etc/sysctl.d/99-openvpn-forward.conf
sysctl --system

İkinci kapı filtre tablosudur. Docker kurulu bir ana makine genellikle FORWARD politikası olarak DROP taşır ve tünel bu kararı devralır. iptables -L FORWARD -v -n hem politikayı hem de paket sayaçlarını gösterir; politika DROP ise iletme, tünelden LAN'a yön için açık bir izin ve yanıt için bir tane daha gerektirir.

Üçüncü adım: paketi LAN'a kadar izleyin ve yanıtı arayın

Sunucunun iki tarafını aynı anda izleyin. Tünelde ve LAN arayüzünde yakalayın, çıktı okunabilir kalsın diye bir istemci ve bir ana makineye filtreleyin:

tcpdump -ni tun0 host 192.168.50.10
tcpdump -ni eth0 host 192.168.50.10

tun0 üzerinde ve ardından eth0 üzerinde 10.8.0.x kaynağıyla görünen, ardından sessizlik gelen istekler, paketin ulaştığı ve yanıtın başka bir yere gittiği anlamına gelir. LAN ana makinesi varsayılan ağ geçidine yanıt verir, o ağ geçidinin VPN havuzu için rotası yoktur ve yanıt LAN yönlendiricisinde ölür. LAN ana makinesine sunucudan ping atmak bu yol hakkında hiçbir şey kanıtlamaz, çünkü o trafik tüneli asla geçmez.

Dördüncü adım: çeviri ile dönüş rotası arasında seçim yapın

İki onarım deliği kapatır ve seçimin ping'in çalışıp çalışmamasının ötesinde sonuçları vardır. Kaynak çevirisi sunucuyu görünen gönderici yapar:

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

Kuralı havuza ve LAN arayüzüne sınırlayın, sonra kalıcı hale getirin, aksi halde bir sonraki güvenlik duvarı yüklemesi düzeltmenizi sessizce kaldırır. Bedeli kimliktir: her istemci LAN günlüklerinde ve erişim kurallarında VPN sunucusu gibi görünür, ve per-client policy becomes guesswork.

LAN yönlendiricisinde VPN sunucusuna işaret eden 10.8.0.0/24 için statik bir rota, istemci adreslerini görünür tutar ve o yönlendirici sizinse daha iyi uzun vadeli yanıttır. Birçok site bir süre ikisini birden çalıştırır, acil onarım için NAT ve güvenlik duvarı politikası yazıldıktan sonra rota. Sunucu havuz değil de site-site eş ise, sunucu tarafının da uzak alt ağ için iroute gerekir, aksi halde eş rotası vardır ama istemci trafiği ona asla bağlanmaz.

Beşinci adım: istemciden doğrulayın ve neyin değiştiğini kaydedin

Döngüyü sunucudan değil istemciden kapatın. LAN ana makinesindeki gerçek bir hizmete bağlanın, sonra iptables -t nat -L POSTROUTING -v -n ile çeviri sayaçlarının hareket ettiğini doğrulayın, çünkü sıfır paketli bir kural hiç eşleşmemiş bir kuraldır. Dönüş yönünün izlendiğine dair kanıt gerektiğinde conntrack -L -s 10.8.0.5 akışı ve durumunu gösterir.

Sunucu yapılandırmasında bir not bırakın: hangi alt ağ, hangi arayüz, hangi kural ve LAN yönlendiricisinin geri dönüş rotası olup olmadığı. Bir sonraki istemci güncellemesi itilen bir rotayı sildiğinde, o not bir yangın söndürme oturumunu tek satırlık bir düzeltmeye çevirir.

İlgili makaleler