VPN bağlıyken yerel ağa erişilemiyor mu? Dört kontrol

Tünel açılır, intranet görünür ve yazıcı yanıt vermeyi bırakır. LAN'da hiçbir şey bozulmamıştır; istemci artık yerel saymadığı adresler için kullandığı yolu değiştirmiştir. Aşağıdaki dört kontrolü sırayla yapın ve biri somut bir uyuşmazlık gösterdiğinde durun, çünkü aynı belirtinin dört yaygın nedeni vardır ve bunlardan yalnızca biri VPN'i düzenleyerek giderilir.

Önce istemcinin kurduğu yönlendirme tablosuna bakın

VPN bağlıyken istemcinin yönlendirme tablosunu açın. Linux'ta ip route, Windows'ta route print veya Get-NetRoute, macOS'ta netstat -rn kullanın. Tünelden geçen varsayılan yolu ve fiziksel varsayılan yola ne olduğunu arıyorsunuz.

Tam tünel istemcisi genellikle 0.0.0.0/0 yolunu değiştirmek yerine iki yarım varsayılan yol ekler: 0.0.0.0/1 ve 128.0.0.0/1. Özgün varsayılan yol görünür kalır ama her aramayı kaybeder, bu yüzden tablo bozulmamış görünürken alt ağ dışındaki tüm trafik yer değiştirir. VPN istemcisi bölünmüş tünel seçeneği sunuyorsa ve ilke izin veriyorsa, en temiz onarım budur.

Tünel varsayılan olarak kalmalıysa bunun yerine yerel alt ağı sabitleyin. Linux'ta yol fiziksel arabirimi ve ağ geçidini adlandırır; Windows'ta kalıcı olması için -p ekleyin ve arabirim numarasını tahmin etmek yerine route print çıktısından okuyun:

sudo ip route add 192.168.1.0/24 via 192.168.1.1 dev wlan0
route add -p 192.168.1.0 MASK 255.255.255.0 192.168.1.1 METRIC 1 IF 12

Sabitlenmiş bir yol yalnızca adlandırdığı adres aynı kaldığı sürece geçerlidir. Her bağlantıda Wi-Fi bağdaştırıcısına yeni numara alan bir dizüstü bilgisayar kuralı yine bozacaktır, bu yüzden onarımın başarısız olduğuna karar vermeden önce arabirim adresini kontrol edin.

İkinci olarak, adresin baştan yerel olduğunu doğrulayın

Hedef bağlı alt ağın içindeyse tünelin varsayılan yolu hiçbir zaman uygulanmaz ve VPN neden değildir. 192.168.1.0/24 ağına sahip istemcide 192.168.1.40 adresindeki yazıcı bağlı yolu kullanır; o adres başarısız olursa VPN'e değil cihaza, anahtara veya istemcinin güvenlik duvarına bakın.

İnsanları yanıltan durum, yerel bir sunucu için genel bir adrestir. LAN içinden yönlendiricinin WAN adresine ulaşıp geri dönmek hairpin NAT gerektirir ve birçok yönlendirici bunu bağlantı noktası yönlendirmesi için hiç uygulamaz. Özel adresi genel adresin yanında test edin. Özel adres çalışıp genel adres çalışmıyorsa VPN yalnızca zaten var olan bir NAT sınırlamasını ortaya çıkarmıştır.

Bir ana bilgisayar adı bunu daha da kötüleştirir. Yerel ad artık genel adrese çözülüyorsa istemci geri dönemeyen yolu denemeye devam eder. Test için özel adresi kullanın, sonra bir bağlantı noktası yönlendirmesi daha eklemek yerine adı düzeltin.

Üçüncü olarak, adları artık kimin yanıtladığına bakın

Kurumsal çözümleyici intraneti bilir ve genellikle bir NAS ana bilgisayar adı, yazıcının Bonjour adı veya yönlendiricinin yerel takma adı hakkında hiçbir şey bilmez. VPN kendi DNS sunucularını ittiğinde bu adlar çözülmeyi bırakır, oysa adresleri hâlâ erişilebilir. Adı doğrudan sorgulayın ve yanıtı cihazın sahip olduğunu bildiğiniz adresle karşılaştırın.

Linux'ta resolvectl query nas.local hangi çözümleyicinin yanıtladığını gösterir. Windows'ta nslookup nas.local sunucuyu adlandırır ve ipconfig /all çözümleyici sırasını gösterir. Yerel sonek artık kurumsal çözümleyici tarafından işleniyorsa ya o soneki yerel çözümleyiciye geri yönlendirin ya da cihaz için IP adresini kullanın.

Keşif ayrı bir katmandır. mDNS ve yayın yönlendirilmiş bir tünelden geçmez, bu yüzden bir cihaz adresle erişilebilirken adı görünmez kalabilir. Bir yansıtıcı veya yerel DNS kaydı bunu çözer; bir yol çözmez.

Dördüncü olarak, diğer makinenin de VPN'de olup olmadığını kontrol edin

Ulaşmak istediğiniz makine de bir VPN istemcisi çalıştırıyorsa oturumunuz gelebilir ama yanıtı diğer tünelden çıkabilir. Bu, kurulan ve sonra takılan bir bağlantı ya da sizin tarafınızda hata vermeden zaman aşımına uğrayan bir RDP ve SSH denemesi üretir. Kendi istemcinizi suçlamadan önce diğer ana bilgisayarın yönlendirme tablosuna ve varsayılan yoluna bakın.

Hizmetin hangi adreste dinlediğini de kontrol edin. Yalnızca tünel adresine bağlı bir dinleyici VPN'den gelen bağlantıları kabul eder ve LAN'dan gelenleri reddeder, yönlendirme kusursuz olsa bile. Bu bir hizmet yapılandırmasıdır, ağ yolu değildir ve VPN adresine kilitlenmiş yönetim arabirimlerinde yaygındır.

Tünele bağlı olmayan bir yönetim yolu tutun: kaynak ağınızı adlandıran statik bir yol, LAN'a bağlı başka bir arabirim veya tüneli tamamen atlayan bir konsol. O yolu oturum düştükten sonra tasarlamak, bir sonraki bağlantıdan önce eklemekten çok daha zordur.

Başarısız olan kontrole uyan onarımı uygulayın

Yönlendirme tablosu yarım varsayılan ele geçirme gösterdiyse ilke izin verdiğinde bölünmüş tüneli, izin vermediğinde sabitlenmiş yerel yolu seçin. Adres genel çıktıysa testi ve adı özel adrese taşıyın. Çözümleyici el değiştirdiyse yerel sonekle sınırlayın veya adresi kullanın. Diğer ana bilgisayar tüneldeyse dönüş yolunu veya dinleyici bağlamasını düzeltin.

Tek bir şeyi değiştirin, sonra aynı kontrolü yineleyin. Yanlış alt ağ için eklenen yol, yazım hatası olan çözümleyici soneki ve yeni numara alan bir arabirimde sabitlenmiş yol, hepsi özgün arıza gibi görünür. Onarımı rastlantıdan ayıran şey yinelemedir.

VPN bağlıyken çalışan yolu, adresi ve çözümleyiciyi not edin. Bir sonraki yeniden bağlantı en az birini değiştirecek ve not, sonraki kesintiyi yeni bir soruşturma yerine kısa bir karşılaştırmaya dönüştürecektir.