Yanıtsız giden ESP, VPN'in öldüğü anlamına gelmez
ESP her ilişkilendirme için tek yönü korur ve hiçbir şeyi onaylamaz. Sunucuyu yanıt vermiyor diye adlandırmadan önce iç konuşmayı ve gelen SA'yı eşleştirin.
IPsec ana bilgisayarında trafiği yakaladınız, ESP paketlerinin çıktığını gördünüz, hiçbir şeyin geri dönmediğini gördünüz ve uzak tarafın bozuk olduğu sonucuna vardınız. Yakalama bu sonucu desteklemiyor. ESP bir konuşmanın tek yönünü korur ve IP katmanında hiçbir şeyi onaylamaz, bu yüzden dönüş ESP'sinin yokluğu, uygulamanın söyleyecek bir şeyi olmadığı anlamına da gelebilir, tünelin ölü olduğu anlamına da. Herhangi bir ucu suçlamadan önce iç alışverişi ve alıcı tarafın durumunu okuyun.
Efsane: her korunan paket bir yanıt hak eder
ESP bir istek-yanıt protokolü değildir. Politikanın seçtiği her şeyi şifreler ve kimlik doğrular; alıcı ise kendi paketini üretmeden o iç paketi doğrular, şifresini çözer ve teslim eder. Hedefin yok saydığı bir UDP sorgusu veya gelen politikanın attığı bir ICMP yankısı, doğru sonuç olarak her iki yönde sessizlik üretir. Bu sessizliği taşıma arızası saymak, hiç var olmamış bir ağ arızasını aramaya sizi gönderir.
Tek yönlü bir yakalamanın gerçekte kanıtladığı, gönderenin yığınının o gözlem noktasında bir şeyi şifrelediğidir. Varış hakkında hiçbir şey ve yanıt verme niyeti hakkında hiçbir şey. Yararlı soru „neden yanıt yok“ değil, „iç konuşma ne üretmeliydi“ sorusudur.
İki SA, iki SPI, bir konuşma
IPsec güvenlik ilişkilendirmeleri tek yönlüdür, bu yüzden normal korunan bir alışveriş ayrı tanımlayıcılara ve bağımsız duruma sahip bir gelen ilişkilendirme ile bir giden ilişkilendirme yürütür. Giden paketin SPI'si için dönüş trafiğini aramak bu nedenle bir kategori hatasıdır, çünkü her yanıt ortağın kendi giden SA'sı altında kendi SPI'siyle yol alır. Bunun yerine çifti trafik seçicileri ve ortağın adreslerine göre eşleştirin.
Anahtar yenileme, eski ve yerine geçen durum çakışabildiğinden resmi birkaç saniyeliğine karmaşıklaştırır. Belirti bir anahtar değişimi civarında başladıysa, yalnızca bağlantı adını değil ilişkilendirme tanımlayıcılarını ve zaman damgalarını birlikte toplayın.
Herhangi bir şey yanıt vermeden önce alıcının yapması gerekenler
| Stage | What to look at | Wrong conclusion if skipped |
|---|---|---|
| Sender encrypts | outbound SA packet counter | "the tunnel is up" |
| Peer receives | inbound SA counter and replay window | "the peer is down" |
| Inner delivery | target host or service logs | "routing is broken" |
| Application replies | the app's own trace | "the reply was dropped" |
| Protected return | the peer's outbound SA | "ESP only works one way" |
Her satır bağımsız olarak başarısız olur ve her arızanın farklı bir sahibi vardır, bu yüzden tek bir yakalama onları ayırt edemez. Gelen sayaç, varışın tek doğrudan kanıtıdır, çünkü kimlik doğrulamayı veya yineleme denetimini geçemeyen bir paket hiçbir yanıt olmadan atılır. Gelen sayacı hareket etmemiş bir ortak bu nedenle size politikası hakkında hiçbir bilgi vermez.
Teslimat, şifre çözmeden ayrı bir adımdır. Durum geçerli olabilir ve paket yine de daha sonra gelen bir politika veya iç hedefi kapsamayan bir rota tarafından atılabilir, bu yüzden temiz bir sayacın paketin istediğiniz yere gittiği anlamına geldiğini varsaymak yerine hedef ana bilgisayarın düz metin görüp görmediğini kontrol edin.
Yerel ESP UDP değildir
Yerel ESP IP protokolü 50'dir; ne TCP ne UDP'dir ve hiç portu yoktur. Bu yüzden UDP 500 üzerinde IKE'ye izin veren bir güvenlik duvarı kuralı veri yolu hakkında hiçbir şey söylemez ve portlar etrafında yazılmış bir filtre tünelin anlaşmasına izin verip içinde taşınan her şeyi düşürebilir. Veri yolunu, gerçekte gözlemlediğiniz modda ayrı olarak test edin.
NAT arkasında biçim değişir: korunan yük UDP içinde, genellikle 4500 portunda, RFC 3948'in tanımladığı gibi yol alır. Herhangi bir kural yazmadan önce etkin modu kaydedin, çünkü yol üzerindeki bir cihaz yerel ESP ile UDP içine sarılmış ESP'yi tamamen farklı ele alabilir ve bazı ara kutular birine izin verirken diğerini düşürür.
Bu olaya ait sayaçları okuyun
Bir strongSwan ana bilgisayarında swanctl --list-sas her ilişkilendirme için paket ve bayt sayaçlarını iki yönde bildirir; bu da „hiç gelmedi“ ile „geldi ve yanıtlanmadı“ arasını ayırmaya yeter. Linux'ta /proc/net/xfrm_stat eksik durum, eksik politika ve protokol hataları gibi toplu başarısızlıkları sayar. Bu toplamlar açılıştan beri birikir ve tek bir ağ ad alanına aittir, bu yüzden büyük bir sayı bir atıf değildir.
Doğru ad alanında olay penceresi çevresinde iki okuma alın ve farkları karşılaştırın, yoksa geçen haftanın hatalarını bu öğleden sonranın kaydına yazarsınız. Ad alanını ve iki zaman damgasını kayda koyun, böylece bir sonraki okuyucu bir toplama güvenmek yerine karşılaştırmayı yeniden üretebilsin.
Aşamayı adlandırın, şüpheliyi değil
Yararlı bir sonuç paketin nerede durduğunu söyler: hiç alınmadı, alındı ve atıldı, teslim edildi ama yanıtsız kaldı veya yanıtlandı ve dönüş yolunda kayboldu. Bunların her biri farklı bir sahibe ve farklı bir sonraki komuta işaret eder. „VPN sunucusundan yanıt yok“ dört ayrı arızayı, yakalamanın hiçbir zaman haklı çıkarmadığı tek bir cümleye indirger.
Yakalamaları dar tutun ve ham çekirdek durumunu kayıtların dışında tutun, çünkü ana bilgisayardan çıkmaması gereken anahtar malzemesi taşıyabilir. Sayaç farkları ve zaman damgaları bir sonraki kişiye devredilmeye değer parçalardır.