Siteden siteye VPN tek yönde çalışıyor: iki farklı arıza

A sitesi B'ye ulaşıyor, B, A'ya ulaşamıyor ve tünel her iki yönde de iyi görünüyor. Tünele dokunmadan önce hangi arızanın gerçekten sizde olduğuna karar verin. B'de başlatılan ve reddedilen yeni bir bağlantı ile A'da başlatılan bağlantıya hiç ulaşmayan yanıt benzer şikayetlere ve tamamen farklı teşhislere yol açar. Biri yoldaki bir ilke veya rota sorunudur; diğeri zaten izin verilmiş trafik için dönüş yolu veya durum sorunudur.

Bu ayrım hangi komutları çalıştırmaya değer olduğunu belirler.

Aynı görünen iki arıza

İlk durumda B'nin ana bilgisayarı A'ya bir SYN gönderir ve hiçbir şey geri dönmez. İkincisinde A'nın ana bilgisayarı bir oturumu başarıyla açar ve yanıt dönüş yolunda kaybolur. İki kullanıcı da bağlantının tek yönlü olduğunu söyler ve ikisi de kaybolan bir paketi tarif eder, bu yüzden yalnızca tarif onları ayıramaz.

Başarısız denemeyi hangi tarafın başlattığını sorun. Bu tek gerçek olası nedenlerin yarısını ortadan kaldırır.

Ardından testin baştan sona aynı ana bilgisayarları ve aynı hizmeti kullandığını doğrulayın. Bir taraftan ping ile diğer taraftan dosya paylaşımı bağlantısı iki farklı şeyi dener ve ağ geçidinden alınan bir teşhis hiçbir kullanıcı trafiğinin kullanmadığı bir tünel adresi seçebilir.

Birinci durum: dönüş yolu yok

Başka bir varsayılan ağ geçidi üzerinden yanıt veren uzak bir sunucu isteği alıp yanıtı başka bir yere yönlendirebilir. Bunun üzerine durumu izleyen güvenlik duvarları asimetrik yanıtı düşürür, çünkü yanıt kurulmuş bir akışa uymaz ve bu tam olarak hiç çalışmamış bir yön gibi görünür. Çeviri başka bir sürüm ekler: hedef çevrilmiş bir kaynak görür ve ona yanıt verir, bu yüzden özgün adres için yazılmış bir kural hiçbir zaman eşleşmez.

Hedefin çeviriden sonra gerçekten gördüğü adresi ve dönüş rotasını özgün alt ağ için değil o adres için denetleyin.

İkinci durum: ilke buna hiç izin vermedi

Ters durum göründüğünden daha basit ve daha yaygındır: bir ofisin merkezi bir hizmeti kullanması ve merkeze asla bağlantı başlatmaması gerekir. Bu asimetri bilinçli bir erişim kararıdır ve tünel tasarlandığı gibi çalışır. Herhangi bir tünel ayarını değiştirmeden önce erişim ilkesini okuyun. Hangi yönün amaçlandığını paket yakalama değil belge söyler. Yakalama yalnızca ne olduğunu gösterebilir, neye izin verildiğini değil.

Çift yönlü başlatma gerçekten gerekiyorsa, platformun desteklediği kural kümesi üzerinden söz konusu hizmetin iznini ekleyin. Tek bir uygulamayı düzeltmek için her alt ağı karşılıklı güvenilir yapmak dar bir gereksinimi geniş bir izne dönüştürür ve bu takas sonradan nadiren gözden geçirilir.

Aynı ana bilgisayarlarda önce ve sonrasını karşılaştırın

İki ayrı denemeyi değil, aynı denemenin iki ucunu izleyin. Başlatan ana bilgisayarın ağ geçidinde ve hedefte yakalama yapın, sonra neyin girdiğini, neyin çıktığını ve uzak tarafın hangi adresi gördüğünü karşılaştırın.

tcpdump -ni any host 10.20.30.40 and port 445
conntrack -L | grep 10.20.30.40
ip route get 10.20.30.40
swanctl --list-sas

Hedefteki yakalama isteği beklenmedik bir kaynak adresle gösteriyorsa yanıt tünelin güvenlik ilkesinde değil çeviri veya yönlendirmede aranmalıdır. Hedef hiç istek göstermiyorsa paket korumalı yoldan hiç geçmemiştir.

Bir düzeltmeden sonra aynı testi aynı ana bilgisayardan yineleyin ve ilgisiz erişimin hâlâ reddedildiğini doğrulayın. “established” tünel durumu tek başına iki sonuçtan hiçbirini desteklemez.