VPN tünel adresiniz neden bir gelen bağlantı noktası açmıyor
Bir tünel adresi istemcinizi ona yönlendirebilen eşlere tanıtır ve asla bir dinleyici oluşturmaz. Bağlamayı, dönüş yolunu ve ardından ilkeyi kontrol edin.
Ofis VPN'ine bağlanın, 8443 numaralı bağlantı noktasında küçük bir hizmet başlatın, tünel adresini bir iş arkadaşınıza gönderin ve istemci hâlâ bağlı olduğunu bildirirken bağlantının başarısız olduğunu izleyin. Tünelde hiçbir şey bozuk değil: adres verildi, oturum açık ve yanıtı taşıyacak paketler hiçbir zaman içeri alınmıyor. Aşağıdaki üç kontrolü sırayla yapın ve başarısız olanda durun, çünkü her birinin düzeltmesi farklı ve yalnızca biri VPN ile ilgili.
Yuva gerçekte nereye bağlıysa oradan başlayın
Herhangi bir şey yönlendirilmeden önce, arayanın ulaşabileceği bir adreste bir şeyin dinlemesi gerekir. Geliştirme sunucuları olağan suçlu, çünkü çoğu varsayılan olarak loopback'e bağlanır ve yalnızca aynı makineden gelen bağlantıları kabul eder. Tünel adresi bu bağlamayı değiştirmez ve işletim sistemi bağlantıyı VPN devreye girmeden çok önce reddeder.
ss -ltnp | grep 8443
netstat -ano | findstr 8443Durumu değil, yerel adres sütununu okuyun. 127.0.0.1:8443 yalnızca loopback anlamına gelir ve düzeltme 0.0.0.0 veya tünel adresinin kendisine bağlamaktır. 0.0.0.0:8443 tüm arayüzlerde kabul eder, bu da makinenin genel bir adresi de olduğunda çoğu kişinin amaçladığından daha geniştir; 10.64.7.15:8443 yalnızca iş arkadaşınızın ulaşabildiği yerde dinleyen dar sürümdür. Aynı çıktıdaki süreç adına da dikkat edin, çünkü önceki bir testten kalan bir örnek, bağlantı noktasının açık görünmesinin ve yanlış içerikle yanıt vermesinin yaygın bir nedenidir.
Ardından o adrese bir şeyin yönlendirip yönlendiremeyeceğini sorun
Bir tünel adresi yalnızca bu öneki tünele göndermek üzere yapılandırılmış eşler için anlamlıdır. İş arkadaşınızın makinesinin kendi tablosu vardır ve tünel alt ağına bir yol yoksa paket varsayılan ağ geçidine gider ve adresin varlığından haberi olmayan bir yerde ölür. Bu, arayan tarafında bir yönlendirme sorusudur, sizin tarafınızda bir izin değil.
| Symptom from the caller | What it usually means | Where to look next |
|---|---|---|
| Connection refused immediately | Nothing is listening on the address the packet reached | The bind address and the process owning the port |
| Connection times out with no reply | A policy dropped the packet, or no route returns | Server forwarding, host firewall, cloud security group |
| Works from the same machine only | Listener is on loopback, or no route reaches the tunnel address | Bind address, then the caller's route to that prefix |
İki istemci arasındaki sunucu da aynı derecede önemlidir. Yaygın uzaktan erişim tasarımında her istemci ağ geçidine giden bir bağlantı açar ve ağ geçidi bu akışların durumunu tutar, böylece yanıtlar zaten bildiği bir yoldan geri döner. Bir istemciden diğerine bağlantı, ağ geçidinin kabul edip iletmesi gereken yeni bir akıştır ve birçok kurulum istemcileri birbirinden yalıtmak için bunu bilerek kapatır. Tüketici VPN hizmetleri genellikle varsayılan olarak yalıtır; kurumsal ağ geçitleri bunu bazen grup bazında izin verir.
Ana makinede herhangi bir şeyi değiştirmeden önce yönü kontrol edin. Tünel adresi ağ geçidinin kendisinden yanıt veriyor ama bir eşten vermiyorsa, fark ağ geçidinin istemciden istemciye ayarıdır ve yerel güvenlik duvarını düzenlemek bunun yerini tutamaz.
Son olarak, akışa izin veren ilkeyi bulun
Yönlendirilmiş bir paket ile yanıt veren bir hizmet arasında üç ilke katmanı vardır: VPN sunucusunun iletme kararı, ana makinenin güvenlik duvarı ve örneğin önündeki herhangi bir bulut güvenlik grubu. Üçü de aynı fikirde olmalıdır ve farklı biçimlerde başarısız olurlar, bu yüzden yukarıdaki tablodaki belirti tarayıcıdaki hata mesajından daha yararlıdır.
Ana makinenin güvenlik duvarı, başarılı bir bağlamadan sonra insanların unuttuğu katmandır, çünkü bağlantı noktasına LAN arayüzünde izin veren bir kural onu tünel arayüzünde otomatik olarak izin vermez. Arayüzle sınırlı kurallar doğru tasarımdır ve aynı zamanda ofisten çalışıp evden çalışmayan bir hizmetin yaygın nedenidir. Kuralın kapsamını okuyun, bağlantı noktası numarasını değil.
Durum bilgili filtreleme ters durumu açıklar. Dizüstü bilgisayarınızdan çıkan bir bağlantı durum oluşturur ve ona verilen yanıtlar gelen kural olmadan geçer. İş arkadaşınızın bağlantısı arkasında durum olmayan tamamen yeni bir akıştır, bu yüzden açık bir izin gerektirir. Bu asimetri, kendi makinenizde çalışan bir tarayıcı oturumunun hizmetin dışarıdan erişilebilir olup olmadığı hakkında hiçbir şey söylememesinin tüm nedenidir.
Bir kontrol başarısız olduğunda tüneli değil tasarımı değiştirin
Gereksinim bir iş arkadaşınızın yerel hizmetinizi açmasıysa, dürüst yanıt genellikle gelen erişim için kurulmuş bir mekanizmadır. Ters SSH tüneli en küçüğüdür: makineniz iş arkadaşınızın zaten ulaşabildiği bir ana makineye dışa doğru bağlanır ve dinleyici o makinede bulunur.
ssh -N -R 8443:127.0.0.1:8443 [email protected]Aktarıcı, SSH sunucu yapılandırmasında GatewayPorts clientspecified gerektirir, aksi hâlde iletilen dinleyici aktarıcıda loopback'e bağlanır ve iş arkadaşınız öncekiyle aynı ret ile karşılaşır. Bir öğleden uzun süren her şey için sağlık kontrolü ve yayımlanan ad için sertifikası olan bir yük dengeleyici veya ingress daha iyi bir araçtır ve iki ağ gerçekten konuşmak zorunda kaldığında her iki alt ağ için yolları olan siteden siteye bir tünel doğru yanıttır.
Bu tasarımların her biri maruziyeti açık hâle getirir ve mesele de budur. VPN, paketleri kullanmaya zaten yetkili olduğunuz ağlar arasında taşır; bir hizmet yayımlamaz ve dizüstü bilgisayarı internete bakan bir ana makineye dönüştürmez. Görev, üç katmandan hangisinin değiştirileceğine karar vermektir ve tünel bunlardan nadiren biridir.