OpenVPN’e bağlısınız ama ping veya SMB paylaşımı yok mu? Üç kapıyı denetleyin

Tünel açılıyor, istemci bir adres alıyor ve uzak LAN’da hiçbir şey yanıt vermiyor. Ping başarısız oluyor, paylaşım açılmıyor ve VPN günlüğü temiz görünüyor çünkü onun bakış açısından oturum sağlıklı. O oturum ile sunucudaki bir dosya arasında üç bağımsız kapı var: yönlendirme ilkesi, hizmetin ihtiyaç duyduğu bağlantı noktaları ve adres yerine yazdığınız ad.

Her kapı farklı bir belirtiyle başarısız olur ve yalnızca ilki VPN sunucusundadır.

Yönlendirme FORWARD zincirindeki bir ilkedir

OpenVPN dinleyicisinin kabulü INPUT üzerinde gerçekleşir, bu yüzden LAN’a yönelen her paket düşürülürken tünel bağlanabilir. tun0 üzerinden gelip LAN arayüzünden çıkan trafik FORWARD’dan geçer ve orada varsayılan DROP ilkesi olan bir ana makine onu sessizce düşürür. Başka herhangi bir şeye dokunmadan önce hem sysctl’i hem zinciri denetleyin: sysctl net.ipv4.ip_forward ve iptables -L FORWARD -v -n.

Amacınızdaki yönü ve ona ait yanıtları izin verin, örneğin tünel arayüzünden LAN arayüzüne bir accept kuralı ve established ile related trafik için bir stateful kural. LAN başka bir yönlendiricinin arkasındaysa o yönlendiricinin istemci havuzuna dönüş yoluna ya da VPN sunucusunda source NAT’a ihtiyacı vardır. Daha fazla kural eklemeden önce o yolu tek bir ping ile doğrulayın, çünkü ulaşılamayan bir kural sayaçta asla görünmez.

SMB birden fazla bağlantı noktasına ihtiyaç duyar

Dosya paylaşımı tek bir TCP 445 konuşması değildir. Keşif UDP 137 ve 138 kullanır, eski NetBIOS oturumları TCP 139 kullanır ve modern SMB oturumları TCP 445 kullanır. Yalnızca 445’i açan bir kural, eşlenen sürücünün çalışıp ağ taramasının çalışmadığı ya da tersinin olduğu sinir bozucu durumu yaratır.

Tünel üzerinden büyük aktarımlar da bozuk paylaşım gibi görünen MSS sorunlarıyla karşılaşır. LAN’ın tam segment boyutunu duyuran bir SYN, tünelin daha küçük MTU’su tarafından düşürülür ve bağlantı el sıkışmasından sonra askıda kalır. Yönlendirme yolunda MSS’i sınırlamak, iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu, bu tür bir tıkanmayı ortadan kaldırır. Dizin listesi yerine birkaç megabaytlık bir kopyayla doğrulayın, çünkü büyük aktarımlar geçmediğinde bile küçük yanıtlar geçer.

Tünel bağdaştırıcısı yeni bir ağ profili olarak gelir

Windows her bağdaştırıcıyı bir ağ profiline sınıflandırır ve yeni tünel bağdaştırıcısı genellikle Public’e düşer; orada dosya ve yazıcı paylaşımı kuralları engellenmiştir. Bu, dosya sunucusundaki ana makine güvenlik duvarının kararıdır, VPN sunucusundaki bir yönlendirme sorunu değildir. İlkenin buna izin verdiğini doğruladıktan sonra kategoriyi bilinçli olarak değiştirin Set-NetConnectionProfile -InterfaceAlias "Ethernet 3" -NetworkCategory Private ile, çünkü kategori hangi gelen kuralların geçerli olduğunu da değiştirir.

Aynı profil, TCP 445 başarılıyken ping’in neden başarısız olduğunu açıklar: Public’te yankı istekleri varsayılan olarak düşürülür.

Adlar yönlendirilmiş bir tüneli kendiliğinden geçmez

NetBIOS ad çözümlemesi ve yerel keşif, yönlendirilmiş bir tünelin taşımadığı yayınlara dayanır. Bu yüzden sunucunun kısa adını yazmak başarısız olurken adresi çalışır ve yalnızca arama bozuk olduğunda paylaşım bozuk görünür. Tünelin dağıttığı çözümleyiciye sunucu için bir DNS kaydı ekleyin ya da kısayolda adresi kullanın.

Dağıtım hâlâ WINS’e bağlıysa, yayın trafiğinin görünmesini ummak yerine istemcide yapılandırın. Ad hatasının güvenlik duvarı hatasıyla karıştırılmaması için önce adresle test edin.

Bir seferde bir katman test edin ve ilk hatayı okuyun

Yukarı doğru ilerleyin: tünelin ağ geçidine ping atın, LAN ana makinesine adresle ping atın, sonra hizmetin bağlantı noktasını Test-NetConnection -ComputerName 10.8.0.5 -Port 445 ile açın ve ancak ondan sonra paylaşımda kimlik doğrulayın. İlk başarısız adım düzeltilecek katmandır ve sonraki her adım o geçene kadar gürültüdür. Bağlantı noktası kapalıyken yanıt veren ping, dosya sunucusunun kendi güvenlik duvarına işaret eder; sessiz ping’lere rağmen açılan bağlantı noktası ise ICMP filtrelemesine işaret eder. Bir şeyi değiştirmeden önce ilk başarısız adımı yazın, çünkü ikinci değişiklik birincinin sonucunu gizler.

VPN sunucusu LAN’ın yönlendiricisi değilse, dönüş yolunu o yönlendiricide doğrulayın sunucuya daha fazla kural eklemeden önce. O olmadan istekler ana makineye ulaşır ve yanıtlar varsayılan yoldan internete doğru çıkar; bu, istemci tarafından tam olarak güvenlik duvarı düşürmesi gibi görünür.

Paylaşım hesabını notlarınızda VPN oturum açmasından ayrı tutun, çünkü başarılı bir tünel dosya izinleri hakkında hiçbir şey söylemez. Eksik bir kuralı atlatmak için SMB’yi internete açmak bir çözüm değildir.