Bir paket yakalamada ilk IKEv2 takasını nasıl okursunuz

Oturumun ortasında alınan yakalamalar, IKEv2 izinin gürültü gibi görünmesinin olağan nedenidir, çünkü kayıt başladığında taraflar zaten anahtar yeniliyor ya da şifrelenmiş yükleri takas ediyordur. Bunun yerine yeni bir bağlantı denemesinden başlayın, böylece dosyadaki ilk mesaj görüşmeyi açan mesaj olsun. Aşağıdaki okuma sırası bunu varsayar ve bir paketin uzak uç hakkında hiçbir şey kanıtlamayı bıraktığı noktayı işaretler. Bu adımı atlamak, çalışan bir tünelin engellenmiş bağlantı noktası olarak teşhis edilmesine yol açar.

Açılış takasını gördüğünüzü doğrulayın

Bir IKEv2 görüşmesi IKE_SA_INIT ile başlar, takas türü 34, mesaj kimliği 0. Başlatan taraf sıfırdan farklı bir SPI seçer ve yanıtlayanın SPI'si ilk istekte sıfır, yanıtta sıfırdan farklıdır. Bu üç olgu yeni bir denemeyi anahtar yenilemeden ya da bir yakalamanın en üstünde duran IKE_AUTH mesajından ayırır.

Başlık alanları okunabilir; teklif, anahtar takası ve nonce yükleri de öyle. Okunabilir olmak doğrulanmış olmak değildir: bu noktada hiçbir taraf kimliğini kanıtlamamıştır ve Diffie-Hellman'ın özel değeri hatta asla görünmez.

Alanları bir kod çözme panelinde kaydırmak yerine tablo olarak yazdırın, çünkü yeniden iletimler ve uyuşmayan SPI'ler sütunlarda belirginleşir.

tshark -r ike.pcapng -Y "isakmp" -T fields -e frame.number -e ip.src -e udp.srcport -e isakmp.exchangetype -e isakmp.messageid -e isakmp.initiator_spi -e isakmp.responder_spi

Çıktıyı çiftler hâlinde okuyun. Mesaj kimliği 0 olan bir isteğin ardından aynı kimliği ve sıfırdan farklı yanıtlayan SPI'sini taşıyan bir yanıt, istek yeniden iletildiği için üç kez görünse bile tek bir takastır. Üç özdeş istek üç oturum açma değildir ve bunları böyle değerlendirmek, istemcinin döngüde döndüğü sonucuna varılmasının yoludur; oysa istemci yalnızca sabırlıdır. Mesaj kimliğine, sonra zaman damgasına göre sıralayın; tüm konuşma kısa bir deneme listesine iner.

Başarıyı okumadan önce reddi okuyun

Bir yanıt otomatik olarak ilerleme değildir. Yanıtlayan, cookie bildirimiyle yanıt verip başlatanın yeniden denemesini bekleyebilir ya da bunun yerine kabul edeceği grubu adlandıran INVALID_KE_PAYLOAD ile. İkisi de düzgün biçimlendirilmiş IKE mesajı olarak gelir ve ikisi de yalnızca paket sayan bir süzgeç için tamamlanmış takas gibi görünür.

Bildirim yükünü açın ve her şeyden önce türünü okuyun. Cookie meydan okuması, yanıtlayanın sahte kaynak adreslerine karşı kendini savunduğu anlamına gelir ve istemci cookie'yi ekleyerek yeniden göndermelidir. Geçersiz grup, iki teklifin uyuşmadığı anlamına gelir; bir tarafın yapılandırması değişmedikçe hiçbir yeniden deneme bunu değiştirmez.

Şifrelenmiş kimliği ve doğrulama yüklerini yalnızca IKE_AUTH, yani ikinci takas taşır. Bu nedenle tamamlanmış bir IKE_SA_INIT, tarafların algoritmalar ve türetilmiş anahtarlar üzerinde anlaştığını söyler ve kimlik bilgilerinin kabul edilip edilmeyeceği hakkında hiçbir şey söylemez. Orada da iki mesaj bekleyin ve oturum anahtarları olmadan ikisinin de opak olacağını bekleyin.

4500 bağlantı noktası tek bir protokol değildir

Açılış takasını genellikle UDP 500 taşır. NAT algılaması çalıştıktan sonra IKE 4500'e geçer ve her mesajın önüne ESP olmayan dört baytlık sıfır işareti koyar. Aynı bağlantı noktasındaki kapsüllenmiş ESP ise sıfırdan farklı bir ESP SPI'si ile başlar ve tek baytlık NAT keepalive, başka hiçbir şey olmadığında ortaya çıkan üçüncü biçimdir.

Yalnızca bağlantı noktasıyla eşleşen bir süzgeç üçünü karıştırır, bu yüzden "4500'de trafik var" çok az şey belirler. Uzak uç hakkında bir sonuca varmadan önce görünümü protokole göre ayırın.

tshark -r ike.pcapng -Y "udp.port == 4500 && isakmp" -T fields -e frame.number -e isakmp.exchangetype
tshark -r ike.pcapng -Y "udp.port == 4500 && !isakmp" -T fields -e frame.number -e esp.spi

Sessizlik gözlem noktasını tanımlar

Yanıtsız istekler tam olarak tek bir şeyi kanıtlar: o yakalama noktasında hiçbir yanıt görünmedi. Filtreleme, yanıtı başka yere gönderen bir yol, erişilemeyen bir yanıtlayan ya da teklifi sevmeyen bir yanıtlayan, hepsi aynı boş sonucu verir ve genel bir UDP denemesi bunları ayırmaz.

ICMP ulaşılamazlığı başka türden bir kanıttır. İçindeki alıntılanan paketi okuyun ve hangi aygıtın gönderdiğini belirleyin, çünkü bir yönlendiricinin yönetsel reddi uzak uçtan gelen doğrulanmış bir hata değildir.

tshark -r ike.pcapng -Y "icmp.type == 3" -T fields -e frame.number -e ip.src -e icmp.code

Aynı denemeyi okumanıza izin verilen yerlerde sunucu tarafı günlükleriyle ilişkilendirin. İstek ulaştı mı, hizmet yanıtladı mı ve yanıt nerede durdu? Bu üç yanıt sizi yol sorununa ya da ilke sorununa gönderir ve dördüncü kez kimlik bilgilerini değiştirmekten daha az maliyetlidir.