Yapılandıramadığınız NAT'ın arkasındaki VPN: hâlâ ne çalışıyor

Her tünel uç noktasının karşı tarafın ulaşabileceği bir adrese ve porta ihtiyacı vardır ve yönetmediğiniz bir yönlendirici bu gereksinimin başarısız olmasının olağan nedenidir. İlginç olan hilelerin var olması değil, her birinin istemciden göremediğiniz bir eşleme tablosunun özelliğine bağlı olmasıdır. Bu özelliklerden ikisi neredeyse her şeye karar verir: eşlemenin nasıl oluştuğu ve iç tarafın hiç temas etmediği bir adresten paket kabul edip etmediği. Ortamı bu özelliklere göre sınıflandırın ve dolambaçlı çözümler folklor olmaktan çıkar.

Eşleme tablosu her şeye karar verir

Ağ adresi çevirisi, iç adres ve portun genel adres ve port karşısında kaydedildiği bir tablo tutar. Bir kayıtla eşleşen yanıtlar geri çevrilir ve dışarıdan gelen, eşleşen kaydı olmayan bir paketin hiçbir hedefi yoktur. Bu tek davranış, yönlendiricinin arkasındaki dinleyicinin internetten neden ulaşılamaz olduğunu açıklar. Her yöndeki ilk paketin neden içeriden başlaması gerektiğini de açıklar.

Tabloya yönlendirici tarafından bakın ve dolambaçlı çözümler apaçık olur: ya bir şey kalıcı bir kayıt oluşturur, ya geçici bir kayıt oluşturup taze tutar, ya da trafik o yolu hiç kullanmaz. Makalenin geri kalanı bu üç durumdur, sırasıyla. Burada hiçbir şey tablonun kaydettiğinin ötesinde bir üretici özelliğine bağlı değildir.

Buluşma hizmetinin neler yapabildiği ve yapamadığı

UDP delik açma, filtreyi yenmek yerine giden kaydı geçici bir açıklık olarak kullanır. İki eş de bir buluşma hizmetine başvurur; hizmet her genel uç noktayı öğrenir ve karşı tarafa kendi uç noktasını bildirir. Sonra ikisi birbirine doğru gönderir ve her giden paket, yanıtın içeri girmesini sağlayan kaydı oluşturur veya tazeler. Sıralama çalışmasını sağlar ve sıralama onu kırılgan da yapar: karşı taraf kaydını oluşturmadan önce gönderen eş basitçe düşürülür, oysa bir an sonraki yeniden deneme başarılı olur. Hizmetin kendisi hiçbir VPN trafiği taşımaz, bu yüzden tek kaldıracı koordine ettiği zamandır.

Eşleme davranışı geri kalanı belirler ve RFC 4787 üç biçimi adlandırır: uç noktadan bağımsız, adrese bağımlı ve adres ile porta bağımlı. Sonuncusunda bir eşin hedeflemesi gereken port her hedefle değişir, bu yüzden tahmin güvenilir olmaktan çıkar. Teknik burada çıkmazlarına ulaşır, çünkü operatör düzeyi NAT ve katı bir kurumsal güvenlik duvarı, şemanın ihtiyaç duyduğu öngörülebilirliği birlikte ortadan kaldırır ve ne kadar yeniden denense de geri gelmez.

Keepalive, yeniden başlatmalar ve hareket eden uç nokta

Delinmiş bir yol dinleyici değil akıştır, bu yüzden üzerinde çalışan her şey değişime dayanmalıdır. Eşlemeyi periyodik trafikle canlı tutmalı, genel uç nokta hareket ettiğinde fark etmeli ve yönlendirici yeniden başladıktan veya adres yeniden atandıktan sonra yeniden kurulmalıdır. Mesh VPN ürünleri bu mantığı kendi denetim düzlemlerine koyar, düz bir sunucu ise bunu size bırakır. Keepalive yalnızca aynı eşleme yaşadığı sürece yardımcı olur ve mobil istemcide pil tüketir, bu yüzden agresif bir aralık bedava değildir.

Bir saat uyuyan bir dizüstü bilgisayar genellikle farklı bir genel uç noktaya döner. Yolu yeniden kuran her şey yeniden içeriden çalışmalıdır, bu da aynı gereksinimi istemciye geri yükler.

Eksik yönlendirmeyi atlatmanın üç yolu

İlk yol, özellik varsa ve açıksa, yönlendiriciden kaydı kendisinin oluşturmasını ister; UPnP IGD, NAT-PMP veya PCP üzerinden. İkincisi trafiği genel adresi olan bir röleye verir; bu her zaman çalışır ve her zaman bant genişliği artı farklı bir güven sınırına mal olur. Üçüncüsü yönü tersine çevirir: iç ana bilgisayar genel bir sunucuya giden tünel açar ve diğer her şey onun içinde gider.

[Peer]
PublicKey = 6yGj3kQ2wVb8sTn1pLx4dRc7hZa9mKf2uYe5oNq0iXw=
Endpoint = relay.corp.internal:51820
PersistentKeepalive = 25
AllowedIPs = 10.44.0.0/24

Röle uç noktası bu takası istemci yapılandırmasında görünür kılar; burada uç nokta eşin kendi adresi değil bir röledir. Kalıcı keepalive eşlemeyi sıcak tutar ve izin verilen önekler istemcinin bunun üzerinden ne gönderebileceğine karar verir. İç ana bilgisayardan ters tünel başka bir sahiple aynı fikirdir ve NAT'ta hiçbir değişiklik gerektirmez. Üçünün her biri gelen gereksinimini ortadan kaldırır, ama tasarımı gereği istenmeyen trafiği engelleyen bir güvenlik duvarını yenmez, çünkü trafik yine içeriden başlar.

Çözümü yönlendiricinin sahibine uyarlayın

Yönlendiriciyi siz yönetiyorsanız, statik UDP yönlendirmesini herhangi bir delik açma şemasından daha kolay denetlersiniz ve gördüğünüz biçimlerde başarısız olur. Yönetmiyorsanız, üreticinin bir röle veya barındırılan denetim düzlemi sunup sunmadığını ve politikanın bunun kullanımına izin verip vermeyeceğini öğrenin. Hiçbiri yoksa kalan seçenekler ters tünel veya uç noktanın dışarıdan ulaşılamaz olduğunu kabul etmektir. Hangisini kullandığınızı kaydetmek göründüğünden daha önemlidir, çünkü seçenekler trafiği kimin gözlemleyebildiği ve üçüncü bir taraf bir şeyi değiştirdiğinde ne olduğu konusunda farklılaşır.

Vardığınız yolun doğrudan mı yoksa röle üzerinden mi olduğunu not edin, çünkü bu tek gerçek hem gecikmeyi hem de hata davranışını öngörür. RFC 4787 bunların altındaki eşleme davranışı için referans olmayı sürdürür ve eşleme bölümünü okumak üç çözümü sırayla denemekten daha hızlıdır. Tablo hangi seçeneği seçtiğinizi umursamaz; yalnızca bir sonraki paketin ne yapmasına izin verildiğini kaydeder.