Dolaşımdaki bir VPN istemcisi ofis için hizmet barındırabilir mi?
Dolaşımdaki bir istemci, ofis sistemlerine yalnızca ağ geçidi ona yönlendirdiğinde, ana makine ilkesi buna izin verdiğinde ve cihaz yeterince uzun süre erişilebilir kaldığında hizmet verebilir.
Ofis dizüstü bilgisayarınız evden bağlanıp yine de ofisin ihtiyaç duyduğu bir şeyi sunabilir, ancak yalnızca üç ayrı karar aynı noktada buluştuğunda. Tünel taşımadır, iç adres hedeftir ve ilke kimin kapıyı çalabileceğine karar verir. Bunlardan herhangi birini bütün yanıt olarak görmek, tanıdık şikâyeti doğurur: ana makine ping yanıtlar ama uygulama asla bağlanmaz. Roller aynı değildir ve fark tam olarak tasarım işinin yaşadığı yerdedir.
Çevirmeli bağlantı yönü hizmet yönü hakkında hiçbir şey söylemez
Bir istemci tünel başlattığında, var olduktan sonra her iki yönün de kullanabileceği bir yol açar. Yeni bir bağlantının merkezden o istemciye doğru girip giremeyeceği ağ geçidi ilkesi sorusudur, bağlanan kişinin özelliği değildir. Örneğin yönlendirilmiş bir OpenVPN merkezinde sunucunun istemcinin iç adresine bir yola ve eş ilişkisine izin veren iletmeye ihtiyacı vardır.
Dolaşımdaki dizüstü bilgisayarlardaki bir aracıyı yoklayan bir envanter sistemi ya da evdeki bir iş istasyonundan test API'sine ihtiyaç duyan bir geliştirici düşünün. İkisi de konuşmayı ofis tarafının başlatmasını ister, bu da olağan istemciden sunucuya modelinin tersidir.
Barındırılan uzaktan erişim ürünleri burada farklılaşır ve bu farklılık bir hata değildir. Bazı yönetilen hizmet VPN'leri, modelleri istemciden kaynağa olduğu için, kaynaktan istemciye değil, bağlı istemcilere yönelik istenmeyen bağlantıları bilerek engeller. Bir iş arkadaşınıza dizüstü bilgisayarının sunucu olarak çalışabileceğini söylemeden önce ürünün belgelenmiş mimarisini okuyun.
Bağlantı noktasını açmadan önce dönüş yolunu izleyin
Yolun üç parçası vardır: ağ geçidinde istemcinin iç adresine işaret eden bir yol, belirli çağırana izin veren bir ilke ve hedefte dinleyen bir hizmet. Her parça farklı biçimde başarısız olur, bu yüzden «VPN açık» neredeyse hiçbir şey söylemez.
İyi haber şu ki iç yol, istemcinin ev yönlendiricisinde bağlantı noktası yönlendirmesine ihtiyaç duymaz. Hizmeti evdeki WAN adresinde değil tünel adresinde yayımlamanın anlamı budur; orada maruz kalma ve NAT kuralları tamamen farklı olurdu. Ev yönlendiricisi ofisten gelen bir bağlantıyı hairpin yapmayı da reddedebilir, bu yüzden WAN yolu VPN'inizle ilgisi olmayan nedenlerle başarısız olur. Trafiği tünelin içinde tutmak iki sorunu birden önler.
Hedef tarafını da denetleyin. Yalnızca 127.0.0.1 adresine bağlı bir hizmet, ağ geçidinin yolları ne kadar doğru olursa olsun, tünel arabirimine gelen bir bağlantıyı kabul edemez. Bağlantı noktasına yalnızca yerel alt ağdan izin veren bir ana makine güvenlik duvarı kuralı da ofis trafiğini düşürür ve o kural yukarıdaki VPN ilkesinden bağımsızdır.
Adlar ve adresler tasarım kararlarıdır
Tünel içindeki bir adres otomatik olarak ad değildir. Denetlediğiniz özel bir DNS kaydı, bir keşif protokolünün tüneli aşmasını ummaktan daha açıktır, çünkü bağlantı yerel çoklu yayın ad çözümlemesi yerel segmentte kalır ve alt ağlar arası DNS'e dönüşmez.
Adres kararlılığı da aynı ölçüde önemlidir. VPN istemcileri kısa kiralamalı bir havuzdan alıyorsa, dizüstü bilgisayarın iç adresi oturumlar arasında değişir ve bunun üzerine kurulu her yer imi, güvenlik duvarı kapsamı ve izleme denetimi sessizce bozulur. Bir rezervasyon ya da belgelenmiş dinamik güncelleme yolu kullanın.
Adı VPN kimliğinin sahibiyle kararlaştırın; böylece kayıt, adres ataması ve erişim ilkesi üç ayrı bilette değil birlikte değişir.
Hizmeti test edin, üyeliği değil
Hedeften neyin hangi adreste dinlediğini doğrulayın, ardından ağ geçidinin dönüş yolu görünümünü doğrulayın:
$ ss -ltnp | grep 8080
LISTEN 0 128 10.80.0.23:8080 0.0.0.0:*
$ ip -4 addr show tun0 | grep inet
inet 10.80.0.23/24 scope global tun0
$ ip route get 10.80.0.1
10.80.0.1 dev tun0 src 10.80.0.23
Şimdi ofis tarafından yankı yerine gerçek bir istekle test edin. Hizmete karşı başarılı bir curl yolu, ilkeyi ve dinleyiciyi aynı anda kanıtlar; başarılı bir ping ise yalnızca ICMP'ye izin verildiğini kanıtlar. İstek başarısız olursa, güvenlik duvarını genişletip ummak yerine üç parçadan geriye doğru gidin.
Kullanılabilirlik aynı konuşmaya aittir. Bir dizüstü bilgisayar uyur, ağlar arasında dolaşır ve günün sonunda bağlantıyı keser. Her saat yanıt vermesi gereken bir hizmet her zaman açık bir ana makinede olmalıdır; en iyi çaba hizmeti ise bu kısıtlama yazılı olmak kaydıyla istemcide kalabilir.
Kaynağı bilinçli olarak yayımlayın, ad, izin verilen çağıranlar listesi ve bir sahiple, ve uzak cihaz kazara bir sunucu değil desteklenen bir hizmet olur.