Tünel açık, internet yok: iletmenin durduğu yer

Kimlik doğrulama ve çalışan bir tünel internet çıkışı anlamına gelmez. Tek bir isteği kaynak adresleme, iletme ve yanıt yolu boyunca izleyin.

İstemci bağlanır, tünel ağ geçidine ping taşır ve ötesinde hiçbir şey yanıt vermez. Bu durum, her zaman yalnızca korumalı ağlara erişim sağlamak için tasarlanmış bir ağ geçidi için normaldir ve tam tünel çıkışı olarak duyurulan bir ağ geçidi için arızadır. Kuralları değiştirmeden önce hangi hizmetin vaat edildiğini doğrulayın. Ardından tek bir genel isteği durabileceği dört nokta boyunca izleyin. Tek bir istek ve tek bir paket yakalama, bir sayfa tahminden fazlasını çözer.

İnternet çıkışının baştan tasarım olup olmadığını doğrulayın

Bölünmüş tünel profili yalnızca korumalı alt ağları VPN'e yönlendirir, bu yüzden genel tarama yerel bağlantı üzerinden devam eder ve ağ geçidine hiç dokunmaz. Tam tünel profili tünele varsayılan bir rota kurar ve bu da ağ geçidini tüm yolun sorumlusu yapar. İkisi de meşru tasarımdır ve karıştırılmaları, olmadığı yerde bir arıza raporu üretir. Başka bir şeyi test etmeden önce istemcinin duyurduğu rotaları okuyun, çünkü rota tablosu kaydın genellikle yanlış sorduğu soruyu yanıtlar.

İstemcinin kurduğu her zaman profilin amaçladığı şey değildir. İtilen bir rota, daha düşük metrikli yerel bir rota tarafından geçersiz kılınabilir ve varsayılan rota eklerken LAN rotasını koruyan istemci, o alt ağ için bölünmüş tünel gibi davranır.

Tek bir genel isteği izleyin

Tek bir hedef seçin ve onu istemciden dışarıya doğru izleyin. İstemcide paketin gerçekten tüneli seçip seçmediğini ve kaynak olarak hangi yerel adresi kullandığını kontrol edin. Ardından ağ geçidini kontrol edin: paket geliyor mu ve genel arayüzden çıkıyor mu. Bu yanıtların her biri bütün bir neden kategorisini ortadan kaldırır.

ip route get 1.1.1.1
ip -4 addr show tun0
conntrack -L | grep 1.1.1.1
tcpdump -ni any host 1.1.1.1

Ağ geçidi paketi hiç görmezse istemci rotası veya tünel seçimi yanlıştır. Paket gelip çıkmıyorsa sorun ağ geçidindedir ve kalan üç kontrol geçerlidir.

İletmeyi, rotayı ve çeviriyi kontrol edin

strongSwan ile gelen iletme kılavuzu her tünel türündeki ağ geçidi için geçerlidir: çekirdeğin paketleri arayüzler arasında taşımasına izin verilmelidir ve kullanılabilir bir rota internete doğru bakmalıdır. Güvenlik duvarı ilkesi ardından trafiğe izin vermeli ve kaynak adres genel tarafın yanıtlayabileceği bir adres olmalıdır. İnternete değiştirilmeden iletilen özel istemci adresi hiçbir zaman yanıt alamaz.

sysctl net.ipv4.ip_forward
ip route get 1.1.1.1
nft list ruleset | grep -A6 forward
sysctl net.ipv4.conf.all.rp_filter

Kaynak çevirisi genellikle eksik olan parçadır. Onunla ağ geçidi istemci kaynağını kendi genel adresine yazar ve akışı izler; o olmadan yanıtın gidecek yeri yoktur. Bulut platformları ikinci bir sınır ekler; burada örneğin rota tablosu veya güvenlik grubu, konuk güvenlik duvarının izin verdiği trafiği düşürebilir. Bu sınırı kaçırmak kolaydır çünkü konuk sistem içeriden doğru yapılandırılmış görünür.

Asimetrik bir düzenekte ters yol filtrelemesi de geçerli paketleri atabilir. O kuralın sayacını okuyun, iyi olduğunu varsaymayın, çünkü genel arayüzdeki katı bir ayar, rota tablosunun öngördüğünden farklı bir yoldan gelen trafiği reddeder.

Yanıt yolu ve çözümleyici iki farklı yanıttır

Yalnızca isteği değil yanıtı da izleyin. İstek çevrilmiş olarak çıkıyorsa ve yanıt çevrilmiş akışa dönüyorsa, uygulama hâlâ başarısız olsa bile iletme çalışıyor demektir ve sonraki inceleme uygulamaya ya da DNS'e aittir.

HTTP hatası döndüren bir site, internete iletmenin çalıştığının kanıtıdır. Adresle erişim çalışırken çözülemeyen bir ad, çözümleyici sorunudur, NAT sorunu değil.

Dar bir düzeltmeden sonra istemciyi ve kasıtlı olarak kısıtlanmış her özel kaynağı yeniden test edin. İnternet erişimi vermek, ağ geçidine bağlı her ağa erişimi sessizce genişletmemelidir.

İlgili makaleler