Azure S2S VPN bağlı ama trafik yok: IKE günlüğünü okuyun

Portal Connected yazıyor, tünelin bir çalışma süresi sayacı var ve sanal makinenizden alınan trace ikinci hop'ta ölüyor. Bağlantı durumu IKE ve IPsec görüşmesini anlatır, tek bir paketin herhangi bir tarafta ilke katmanını atlatıp atlatmadığını değil. Bu biletlerin çoğunu iki arıza açıklıyor ve ikisi de Azure rotasını değiştirerek düzelmiyor. Her ikisi de ağ geçidinin ürettiği günlükte zaten yazılı, bu yüzden rota tablosundan değil oradan başlıyorum.

Connected gerçekte neyi onaylıyor

Bağlı bir site-to-site bağlantı, 1. ve 2. fazların tamamlandığı ve güvenlik ilişkilerinin ayakta olduğu anlamına gelir. Bu, görüşme hakkında bir ifadedir: iki taraf bir öneri üzerinde anlaştı, anahtar alışverişi yaptı ve SA çiftini kurdu. Korumalı olduğunu düşündüğünüz alt ağlarla trafik seçicilerinin eşleşip eşleşmediği hakkında hiçbir şey söylemez, şifre çözüldükten sonra karşı tarafın paketi bir yere yönlendirip yönlendirmeyeceği hakkında da. Tünel haftalarca ayakta kalıp ilginç her akışı düşürebilir ve insanları sağlıklı bir ağ geçidini yeniden kurmaya iten tam olarak bu örüntüdür.

İlk bakılması gereken iki arıza, ESP yerine AH öneren bir peer ve ağ geçidinin iç kabul etmeyeceği bir alanda numaralandırılmış sanal ağdır.

Rotalara dokunmadan önce dışa aktarılan günlüğü açın

Portalda sanal ağ geçidini açın ve bağlantı üzerinde VPN troubleshoot işlemini çalıştırın, ardından ürettiği paketi indirip açın. İçinde 1. ve 2. faz alışverişlerini içeren bir IKE günlüğü var, zaman damgalı ve düz metin olarak okunabilir. Baştan sona okumak yerine içinde transform satırını arayın, çünkü ilginç kayıt genellikle birkaç yüz satır içeridedir. Portal erişiminiz yoksa, tanılama ayarları açıkken aynı tanılamalar ağ geçidinin günlük hedefinde görünür.

İki kayıt değerin büyük kısmını taşır. Birincisi yaklaşık olarak expected ESP with combined authentication and cipher, received AH diye okunur. İkincisi IKE alışverişi sırasında geçersiz payload hatasıdır ve genellikle yanlış biçimlendirilmiş veya desteklenmeyen bir öneri alanı anlamına gelir.

Her ikisi de yerel cihazın ne önerdiğini anlatır, yani ikisi de peer tarafındaki ayarlardır. Bağlantının Azure tarafını yeniden üretmek güvenlik duvarınızın gönderdiği öneriyi değiştirmez ve yine de bunu yapmak bu iş akışındaki en çok boşa giden saattir. Peer üzerinde 2. fazı birleşik kimlik doğrulama ve şifreleme ile ESP'ye ayarlayın ve algoritmayı müzakere etmesine izin verin, sonra combined mode gibi bir ad taşıyan bir üretici onay kutusunun altında sessizce AH önerisi seçip seçmediğini kontrol edin.

Sanal ağın adres alanını doğrulayın

Ağ geçidi sanal ağın özel aralıklarda olmasını bekler. Genel bir blokta numaralandırılmış bir ağ, örneğin 111.x ile başlayan bir ağ, tüneli yukarı kaldırabilir ama Azure bu alanı iç kabul etmeyi reddeder, bu yüzden bağlantı sağlıklı görünür ve hiçbir akış kabul edilmez. Bir öğleden sonrayı seçicilere harcamadan önce adres alanını doğrulayın. Numaralandırma eski bir tahsisattan gelen katı bir gereklilikse, çözüm başka bir ağ geçidi değil adres planının değiştirilmesidir.

Adres alanı dikey penceresindeyken yerinde aralıklarla örtüşmeyi not edin, çünkü örtüşen önekler istemci tarafından benzer görünen farklı bir arıza üretir.

Önekleri iki yönde doğrulayın

Yerel ağ geçidi kaynağı yerinde önekleri tutar ve bunlar uzak cihazın gerçekten koruduğu alt ağlarla eşleşmelidir. Cihazın düşürdüğü adresleri içeren bir özet bazı akışları geçirir, bazılarında başarısız olur; bu da yapılandırma uyuşmazlığından çok aralıklı bir yönlendirme arızası gibi okunur. Uzak tarafı da kontrol edin: bir uç /16 listelerken diğeri onun içinde üç /24 listeliyorsa bu klasik kısmi başarısızlıktır. İki listeden hiçbiri tek başına yetkili değildir, bu yüzden görebildiğinize güvenmek yerine ikisini yan yana karşılaştırın.

Önek değişikliği her zaman kendiliğinden alınmaz, bu yüzden bağlantı nesnesini yeniden kaydetmeyi veya yeniden oluşturmayı planlayın ve ardından yeni öneklerin iki tarafta da göründüğünü doğrulayın.

Ping değil, yolu test edin

Çalışan bir tüneli çalışan bir rotadan ayıran trace şöyle görünür: ilk hop yerinde ağ geçididir, sonra yanıt vermeyen birkaç hop, sonra uzak ana bilgisayar yanıtlar. Trace ana bilgisayara hiç ulaşmıyorsa uygulamanın gerçekten kullandığı TCP bağlantı noktasını test edin, çünkü ICMP yeterince sık filtrelenir ve başarısız bir ping çok az şey kanıtlar. Aynı trace'i uzak bir ana bilgisayardan Azure'daki sanal makineye doğru çalıştırın. İki sonuç arasındaki asimetri, eksik bir dönüş rotasını veya yalnızca tek yöne izin veren bir kuralı bulmanın en hızlı yoludur.

Peer önerisini, iki adres alanını ve bağlantının oluşturulma zamanını bilete yazın, böylece sonraki mühendis hangi değerlerin yeniden kurulduğunu ve hangilerine hiç dokunulmadığını bilsin.

Günlük boş dönerse, ağ geçidi bağlantınızı hiç sonlandırmıyor olabilir. Yerel ağ geçidindeki peer adresinin günlüğü okuduğunuz cihazla eşleştiğini doğrulayın, çünkü tek bir abonelikteki iki ağ geçidi yeniden kurulum sırasında kolayca karıştırılır. Bu hata bir güne mal olur ve hiçbir günlükte iz bırakmaz.