Ağ geçidi kendi yönetim sayfasını barındırıyor: iç veya genel adres

VPN ağ geçidinin kendisindeki bir hizmet, tünelin ulaşabileceği bir iç girişe ihtiyaç duyar. Hizmeti özel olarak yayımlayın, ardından genel dinleyicinin hâlâ açık olmadığını doğrulayın.

Yönetim sayfası mobil verideki bir telefondan yanıt verir ve VPN'e katılan dizüstü bilgisayardan zaman aşımına uğrar. Tünelde bozuk bir şey yok, çünkü istek hiçbir zaman tünele girmez. Ana bilgisayar adı ağ geçidinin genel adresine çözülür ve bu adrese yalnızca sonlandırdığı tünelin dışından ulaşılabilir. Bunu düzeltmek, hizmete özel bir giriş vermek demektir; dış uç noktayı oradan oraya taşımak değil.

Sayfa tünelden değil, dışarıdan yüklenir

İki farklı istek karşılaştırılıyor. Mobil veriden tarayıcı doğrudan genel adrese ulaşır. Tünelin içinden aynı ad aynı genel adrese çözülür ve paketin artık tünelin kendi uzak tarafındaki bir adrese ulaşmak için tünelden çıkması gerekir. Aynı ad, aynı adres, iki çok farklı konum.

Hedef rotası bir adres seçer, bağlantı noktası değil. Yönlendirme tablosunda hiçbir şey 443 numaralı bağlantı noktasının yönetim, 1194 numaralının ise taşıma olduğunu bilmez, bu yüzden ikisi de aynı hedef sayılır.

Bu yüzden sayfa bazen çalışır bazen çalışmaz; istemcinin hangi adı ve hangi ağı kullandığına bağlıdır. Bu bir yol sorunu, kimlik doğrulama sorunu değil. İki istemci de gayet iyi kimlik doğrular.

Dış uç noktayı ulaşılabilir tutun

Tam tünel profilleri VPN uç noktası için istisna rotası gerektirir ve OpenVPN'in redirect-gateway seçeneği tam olarak bunu belgeler: uzak uç nokta önceden var olan ağ geçidi üzerinden bir rota tutar, böylece tünel kendisine yönlendirme yapmaz. Bu istisnayı kaldırın, şifreli taşıma tüneli izler ve oturum bir döngüde biter. Uç nokta adresinin tünelin içinden ulaşılabilir kalmasının nedeni tam olarak bu istisnadır.

Sonuç, genel adresin istemciden ulaşılabilir kalmasıdır; bu yüzden o adrese yapılan tarayıcı isteği de aynı istisnayı izleyip tünele girmeden çıkabilir. İstisna işini yapıyor ve zararı ad veriyor.

Herhangi bir şeyi değiştirmeden önce arayüz listesini değil, rota kararını okuyun. Aşağıdaki komutlar envanteri değil, kararı yazdırır. Bunları başarısız olan istemciden çalıştırın.

ip -4 route get 203.0.113.77
ip -4 rule show
ip -4 route show table all

Arama, uç nokta rotasını fiziksel ağ geçidi üzerinden gösteriyorsa davranış doğrudur ve yönetim sayfası yalnızca yanlış yola gönderiliyordur. Ad çözümlemesinin düzeltmeye dönüştüğü yer tam burasıdır.

Hizmete özel bir ad verin

Hizmetin tünelin içinde ağ geçidinin adresine çözülen bir ada ihtiyacı vardır; aynı zamanda uygulamanın beklediği sertifika ve ana bilgisayar adı anlamı korunmalıdır. Yönetim adı için özel bölge kaydı olağan yanıttır, ve taşıma adını dokunulmadan bırakır.

Taşıma adını iç adrese yeniden yönlendirmeyin, çünkü bir sonraki tünel kurulumu yalnızca tünelin içinde var olan bir adrese ulaşmaya çalışırdı. Bu hata tam olarak bir kez çalışan bir VPN üretir.

Her iki adres ailesini de denetleyin, çünkü geride bırakılan bir AAAA kaydı tarayıcıyı özel planın hiç kapsamadığı bir yere gönderebilir.

dig +short admin.hq.internal
dig +short -t AAAA admin.hq.internal
curl -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://admin.hq.internal/

İlkeyi sürecin çalıştığı yere uyarlayın

Ağ geçidinde dinleyen yerel bir sürece yerel giriş yoluyla ulaşılır, bu yüzden giriş zinciri ve soket bağlaması isteğin kabul edilip edilmeyeceğine karar verir. Yönlendirme kuralları ve IP yönlendirmesi yerel bir dinleyiciyi yanıt vermeye zorlamaz. Giriş ilkesinde tünelin kaynaklarına izin verin ve sürecin tünelin ulaşabileceği bir adrese bağlı olduğunu doğrulayın.

Ana makine bağlantı noktasında yayımlanan bir konteyner farklı bir yol izler, çünkü paket hedefe göre çevrilir ve iletilir. Bu istek ana makinenin iletme ilkesiyle ve Docker'ın kendi kurallarıyla karşılaşır, bu yüzden çalışan yerel bir dinleyici aynı bağlantı noktasını reddeden bir konteynerle bir arada var olabilir.

Başlatma sırası her iki durumda da önemlidir, çünkü yalnızca tünel açıldıktan sonra ortaya çıkan bir adrese bağlanma önyüklemede sessizce başarısız olur.

Özel erişimi ve reddedilen genel yolu denetleyin

Uygulamanın kendi kimlik denetimleri bozulmadan yetkili bir istemciden yeni adlandırılmış bir istek yapın. Ardından aynı hizmeti tünelin dışından deneyin ve yanıt vermediğini doğrulayın. Özel ad bir kolaylıktır, kısıtlama değildir ve genel adrese hâlâ bağlı bir dinleyici hâlâ açıktadır. En çok atlanan denetim bu son denetimdir.

Kullanıcılara verilen ana bilgisayar adını değil, bağlamaları ve filtre durumunu okuyun. Açığa çıkma adın değil, soketin özelliğidir. Bu ayrım her DNS değişikliğinde ayakta kalır.

ss -lntp | grep ':443'
nft list ruleset | grep -n 443
curl -sS -m 5 -o /dev/null -w '%{http_code}\n' https://203.0.113.77/

İç istek sayfayı döndürüp dış istek zaman aşımına uğradığında hizmetin kasıtlı tek bir özel yolu vardır ve taşıma ulaşılabilir kalır. Dış istek hâlâ yanıt verdiğinde, biri hizmeti yalnızca iç olarak tanımlamadan önce dinleyicinin veya yayımlanmış bir konteyner girdisinin daraltılması gerekir.

İlgili makaleler