VPN üzerinden ping: yankı yanıtı kuralları neden dönüş yolunu kaçırır

Bir ana bilgisayara VPN üzerinden ping atın: istek bir ICMP türüyle çıkar ve başka bir türle geri döner; bu bile portlar cinsinden yazılmış her kuralı şaşırtmaya yeter. Yankı alışverişinde dönüş kuralına kopyalanacak bir hedef hizmet portu yoktur ve simetri bekleyen bir filtre, istek engelsiz geçerken yanıtı düşürür. Düzeltme, paketi gerçekte olduğu gibi okumakla ve ardından yol üzerindeki hangi sınırın kararı verdiğini belirlemekle başlar. Genellikle iki katman çalışırken üçüncüsü yanıtı sessizce düşürür. Aşağıdaki bölümler onları paketin karşılaştığı sırayla ayırır.

Paket portu değil türü değiştirir

Yankı isteği ICMP tür 8, kod 0’dır ve bir tanımlayıcı ile sıra numarası taşır. Yanıt tür 0, kod 0’dır; tanımlayıcı ve sıra aynıdır, IP uçları ise yer değiştirmiştir. Bu alanları RFC 792 tanımlar ve gönderenin yanıtları kendi istekleriyle eşleştirmesini sağlayan şey tanımlayıcıdır.

Eksik olan da aynı ölçüde önemlidir: TCP veya UDP başlığı yoktur, dolayısıyla izin verilecek bir port da yoktur. Yankı yanıtı için port adlandıran bir kural, hiçbir zaman var olmayacak bir paketi tanımlar. Bu, VPN ping taleplerindeki en yaygın hatadır. Kural belirli görünür, hiçbir şeye uygulanmaz ve arızayı tam olarak olduğu yerde bırakır.

Paketi üç bağlam belirler

Ping uzaktaki LAN’daki bir ana bilgisayarı hedefliyorsa istek ağ geçidi tarafından yönlendirilmelidir. Ağ geçidinin kendisine ait bir adresi hedefliyorsa yerel giriş yolunda sonlanır. Ping’i ağ geçidinin kendisi başlatıyorsa paket kendi çıkış yolunda başlar ve yönlendirme kararından hiç geçmez.

Bu üç bağlamın kural zincirleri ve sayaçları farklıdır ve onları tek saymak, «güvenlik duvarı ICMP’ye izin veriyor» denmesine rağmen ping’in başarısız olabilmesinin nedenidir. Dış tünel dördüncü bağlamdır: VPN dinleyicisine izin vermek, kapsülü çözülmüş iç isteğe otomatik olarak izin vermez ve iç izin, dış tünelin ayakta olup olmadığı hakkında hiçbir şey söylemez.

Durum tutan ve tutmayan filtreler yanıtı farklı ele alır

İsteğin çıktığını gören durum tutan bir güvenlik duvarı yanıtı o akışa bağlayabilir ve ikinci bir kural olmadan geçirebilir. Durum tutmayan filtrenin böyle bir belleği yoktur, bu yüzden dönüş yönü kendi açık iznine ihtiyaç duyar; kaynak ve hedef yer değiştirilir.

Herhangi bir şey yazmadan önce ürünün gerçekte hangi modeli uyguladığını denetleyin. Yankı isteği için bir kural, yankı yanıtını zorunlu olarak kapsamaz ve ICMP sorgularını izleyen bir ürün, başka bir arabirime gelen yanıtlara yine farklı bir politika uygulayabilir.

İzin verdiğiniz şeyin kapsamını sınırlayın. Her yankı yanıtına her yerden izin vermek, durum tutan bir ilişkilendirmeyi tamamlamakla aynı şey değildir ve tür numarası göndereni doğrulamaz.

Çeviri tanımlayıcıyı da değiştirir

Kaynak çevirisi bilinçliyse uzak uçtaki demet, istemcinin gönderdiğiyle eşleşmez. NAT, ICMP sorgusunun tanımlayıcısını adreslerle birlikte çevirebilir, bu nedenle aynı numaranın iki tarafta da görünmesinde ısrar etmek yanlış bir uyuşmazlık üretir.

Bunun yerine çeviricinin bildirdiği eşlemeyle ilişkilendirin. Tanımlayıcıyı yeniden yazan bir çevirici, istemcinizin kaydettiği numarayı korumaz; bu yüzden kimlik olarak numarayı değil eşlemeyi alın. Ardından tanınabilir tek bir isteği yol boyunca izleyin: beklenen kaynakla hedefe ulaştığını doğrulayın, hedefin bir yanıt gönderdiğini doğrulayın, o yanıtın dönüş rotasını izleyin, ve istemcinin onu aldığını doğrulayın; yalnızca ağ geçidi sayacının arttığını izlemekle yetinmeyin.

ICMP hatalarını yankı politikasına katmayın

Yol MTU keşfinin kullandığı «parçalama gerekli» iletisi bir yankı yanıtı değildir ve yükü onu tetikleyen paketi alıntılar. Yalnızca yankıya izin veren bir kural bu hataları sessizce atarsa, boyut sorununu askıda kalan bir bağlantıya çevirir; bu da yararlı olmanın tam tersidir.

Aynı özen adres aileleri için de geçerlidir. ICMPv6 farklı ileti türleri kullanır ve IPv4’te olmayan temel işlevleri taşır; bu numaraları bir IPv6 kuralına kopyalamak yalnızca yanlıştır.

Yankı alışverişi çalıştığında gerçek uygulamayı ayrıca sınayın. Başarılı bir ping, bir protokolün bir boyutta bir hedefe gidip dönmesini kanıtlar ve HTTPS, SMB ya da başka herhangi bir akışın izinli olduğunu varsayma lisansı değildir.