Hairpin NAT: VPN uç noktası neden içeriden başarısız olur

Mobil ağdan yanıt veren ama kanepeden çalışmayan bir VPN sunucusu genellikle sertifika sorunu değildir. LAN içindeki istemci, yönlendiriciden hedefi yönlendiricinin kendi genel adresi olan bir paketi çevirmesini ister, yani paket dışarı çıkıp hemen geri girmelidir. Bu manevraya hairpinning denir ve birçok yönlendirici bunu ya hiç uygulamaz ya da yalnızca bir onay kutusu etkinleştirildiğinde yapar. Dışarıdan yapılan testin geçmesi kafa karıştırıcıdır, çünkü dinleyicinin ve yönlendirme kuralının doğru olduğunu kanıtlar.

Paket dışarı çıkar ve tekrar içeri girer

Paketi izleyin. İstemci genel adı çözer, genel adrese bağlanır ve yönlendiricinin hedef NAT'ı hedefi iç sunucuya yeniden yazar. Sunucunun yanıtı istemcinin LAN adresine adreslenmiştir, bu yüzden kaynağı geri çevirecek NAT kuralından hiç geçmeden yönlendiricinin LAN arayüzünden geri döner.

Şimdi istemci hiçbir şey göndermediği bir adresten paket alır ve onu atar. Bütün arıza bu asimetridir.

RFC 4787 bu durumda bir NAT'tan beklenen davranışı açıklar ve kısa versiyonu şudur ki teoride belirtildiği yerde bile pratikte isteğe bağlıdır. Bazı yönlendiriciler bu ayarı NAT loopback, bazıları hairpin NAT veya NAT reflection olarak adlandırır, bazıları ise hiçbir şey göstermez. Bu özelliği olmayan bir yönlendirici yanlış yapılandırılmış değildir; olağan şeyi yapıyordur ve düzeltme başka bir yere aittir. Başarısız bir yerel testten genel yönlendirme kuralının yanlış olduğu sonucunu çıkarmayın.

Kontrol 1: iki yolu ayrı ayrı test edin

LAN dışından, gerçek bir kullanıcının kullanacağı aynı profille bağlanın ve oturumun kurulduğunu doğrulayın. İçeriden aynı profille genel adrese bağlanın ve tam hatayı ve saati kaydedin.

Kesin bir yerel test ana bilgisayar adını korur ve yalnızca adresi değiştirir: curl -v --resolve vpn.example.com:443:203.0.113.10 https://vpn.example.com/ isteği genel adrese gönderirken doğru sunucu adını sunmaya devam eder. Bu, ad çözümleme sorununu çeviri sorunundan ayırır; aynı ad bir kafeden çalıştığında ikisi kolayca karıştırılır. İstemcinin TCP bağlantısında mı yoksa daha sonra TLS'te mi başarısız olduğunu not edin, çünkü ilki çeviriyi, ikincisi kimliği işaret eder.

Kontrol 2: sunucunun ne gördüğünü okuyun

En yararlı gözlem sunucunun bakış açısıdır. VPN ana bilgisayarında istemcinin LAN adresine ve yönlendiricinin LAN adresine göre filtrelenmiş bir yakalama çalıştırın, sonra yerel denemeyi yineleyin. Hiçbir şey ulaşmazsa paket çeviriden sağ çıkamamıştır.

Bağlantı istemcinin adresi yerine yönlendiricinin LAN adresinden geliyorsa hairpinning oluyor ve kaynak yeniden yazılmıştır. Bu çalışan bir yapılandırmadır, arıza değildir.

Kontrol 3: dış yola dokunmadan düzeltin

Etki yarıçapı artan sırayla üç desteklenen biçim vardır. En dar olanı bölünmüş DNS'tir: aynı sunucu adının LAN'daki istemciler için iç adrese çözümlenmesi için bir iç kayıt yayımlayın, bu da genel yolu tamamen atlar. Bir sonraki, yönlendiricinin belgelenmiş loopback veya reflection seçeneğini varsa etkinleştirmek ve yalnızca bu hizmete uygulamaktır. En geniş olanı, yönlendirici üzerinde LAN'dan gelen trafiği sunucuya yeniden yazan bir source-NAT kuralıdır, böylece yanıt yönlendirici üzerinden geri döner; bir Linux yönlendiricide bu, sunucunun adresi ve bağlantı noktasıyla eşleşen MASQUERADE kuralının POSTROUTING içinde tanımlanmasıdır. Üçü de dış yolu dokunulmamış bırakır ve korunması gereken özellik budur.

Yerel yolu dış yola benzetmek için ilgisiz bağlantı noktası yönlendirmesini genişletmeyin ve sorundan kaçınmak için hizmeti başka bir bağlantı noktasına taşımayın. Her iki değişiklik de yalnızca iç dünyanın gördüğü bir şeyi düzeltmek için dış dünyanın nereye ulaşabileceğini değiştirir.

Bölünmüş DNS'in adlandırılmaya değer bir tuzağı vardır. Bir ana bilgisayar adını rastgele bir IP ile değiştirmek istemcinin neyi doğruladığını değiştirir, bu yüzden iç kayıt yine de sertifikadaki adla eşleşmelidir.

Kontrol 4: ardından iki yolu da doğrulayın

Dış denemeyi LAN dışından yineleyin, iç denemeyi aynı profille yineleyin ve sunucu günlüğünün bir başarı ve bir sessizlik değil, iki ayrı başarılı oturum gösterdiğini doğrulayın. Ardından diğer istemcilerin dinleyiciye hâlâ ulaştığını ve özel kaynaklara giden yolların değişmediğini kontrol edin.

Kaydı kısa tutun: hangi istemci hangi adresi kullandı, sunucu ne gördü ve üç düzeltmeden hangisi uygulandı. RFC 4787'nin hairpinning gereksinimleri burada bir NAT'tan ne beklendiğinin referansıdır ve bu özelliği olmayan bir yönlendiricinin neden normal davrandığını açıklar. Dış dünyanın yeniden üretemediği yerel bir arıza, aksi kanıtlanana kadar bir çeviri sorusudur, bu yüzden onu öyle test edin.