VPN bağlantı noktası gereksinimleri: karşılaştırmadan önce yazılacak üç satır

VPN hizmetlerinin bağlantı noktası listeleri, önemli olup olmadıklarına karar veren ayrıntı olmadan karşılaştırma sayfaları arasında kopyalanır: bağlantıyı kim başlatır. Giden TCP 443'e izin veren bir kural, başka bir ana makinenin sizin makinenizdeki bir dinleyiciye ulaşıp ulaşamayacağı hakkında hiçbir şey söylemez. Tek bir planı karşılaştırmadan önce üç ayrı gereksinim yazın ve görevinizin gerçekten hangilerine ihtiyaç duyduğunu işaretleyin. O sayfa var olduğunda çoğu karşılaştırma tek bir kısa soruya indirgenir.

Herhangi bir bağlantı noktası listesini okumadan önce gereksinimi ayırın

Üç satır neredeyse her durumu kapsar: tünelin ötesindeki bir hedefe ulaşmak, başkalarının içeri bağlanabilmesi için bir şey yayınlamak ve tünelin kendisini taşımak. Her satır farklı bir nedenle başarısız olur ve birini karşılayan sağlayıcı politikası diğer ikisine dokunmayabilir. Görevi doğru satıra yerleştirmek beş dakika sürer ve sonradan bir tartışmayı önler.

Pazarlama ifadeleri üç satırı kasıtlı olarak bulanıklaştırır. P2P izni bir hedef politikası tanımlar, özel adres bir adres tanımlar ve bağlantı noktası kısıtlaması olmadığı iddiası genellikle planın bunları listelemediği anlamına gelir. Bu ifadelerin hiçbiri diğerlerini yanıtlamaz.

Somut bir akış seçin ve cümle olarak yazın: başlatan, taşıma, bağlantı noktası, adres ailesi, yön. Uzak bir ana makineye yükleyen gece yedekleme istemcisi yalnızca gidendir. Masanızdaki, arkadaşların katıldığı oyun sunucusu gelen taraftadır. İkisini tek bir tünelden geçirmek, sayfanın her iki satıra da ihtiyacı olduğu anlamına gelir; aralarında bir uzlaşma değil.

Giden erişim tünelde değil, hedef politikasında başarısız olur

Çeviri yapan bir ağ geçidinden geçen giden trafik durum yaratır. İç adres ve bağlantı noktasından gelen ilk paket bir çeviri kaydı oluşturur ve yanıtlar onunla eşleşir; bu, RFC 3022 içinde tanımlanan eşleme davranışıdır. Bu mekanizma, bir tarayıcı sekmesinin genellikle hiçbir bağlantı noktası isteği olmadan çalışmasının nedenidir.

Yine de iki şey bunu bozar. Çıkış düğümü kötüye kullanılabilir saydığı hedefleri veya bağlantı noktası numaralarını filtreleyebilir ve uygulama çıkış politikasının hiç beklemediği bir bağlantı noktasında dinliyor olabilir. Gelen kuralları değil hedef çiftini sorun ve TCP ile UDP için farklı yanıtlar bekleyin.

Tartışmadan önce ölçün. Bunları tünelin arkasında duracak makinede çalıştırın; bir kez tünel kapalıyken, bir kez açıkken:

ss -lntup | sort
nc -vz -w 3 203.0.113.10 443
curl -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://example.com

Aynı komutlar, aynı hedef, iki tünel durumu, bir operatöre üzerinde hareket edebileceği bir öncesi-sonrası karşılaştırması verir. Belge adresini gerçekten ihtiyaç duyduğunuz ana makineyle değiştirin; önemli olan karşılaştırmanın yinelenmesidir, herhangi bir sayının etkileyici görünmesi değil.

Gelen yayınlama bir eşleme, bir adres ve bir ömür gerektirir

Kamusal tarafta bir şeyin nereye teslim edeceğini bilmediği sürece dışarıdan hiçbir şey dinleyicinize bağlantı başlatamaz. Operatörün tuttuğu statik bağlantı noktası rezervasyonu, istemcinin UPnP, NAT-PMP veya PCP aracılığıyla istediği eşleme ve yönlendirilmiş bir genel adres, üç farklı ürün ve üç farklı sınır demektir.

Bunlardan herhangi birine beş soru sorun: hangi protokol, hangi dış bağlantı noktası, dış bağlantı noktası yerelden farklı olabilir mi, hangi adres ailesini kapsıyor ve eşleme yeniden bağlanmadan sonra ne kadar sürüyor. Etkin bir oturuma bağlı rezervasyon, o oturum sona erdiğinde kaybolur; plan sayfası ne derse desin.

Önce yerel yarıyı doğrulayın, çünkü ölü bir dinleyici ile engellenmiş bir gelen yol dışarıdan aynı görünür:

ss -lntup | grep -E ':(8080|51820)\b'
python3 -m http.server 8080 --bind 0.0.0.0
curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080

Yerel istek 200 döndürdüğünde ve denetlemediğiniz bir ağdan gelen istek hâlâ zaman aşımına uğradığında, boşluk kamusal taraftadır. Uygulamayı adıyla tanımlamak yerine operatöre protokolü ve dış bağlantı noktasını söylemenin zamanı odur.

Tünelin kendi taşıması ayrı bir sorudur

Taşıyıcı bağlantı noktaları sorunun en küçük parçası ve bulunması en kolay olanıdır. Varsayılanlar protokole göre değişir ve istemcinin neyi müzakere edebildiği herhangi bir plan açıklamasından daha önemlidir.

Giden UDP'yi atan bir ağ TCP 443 tünelini kabul eder ve UDP'yi reddeder, bu yüzden yedek bir mod gereksinim sayfasına aittir. Taşıyıcıyı değiştirmek tünel içindeki uygulama bağlantı noktasını taşımaz ve hedef politikasını genişletmez; onlar kendi satırlarında kalır.

Parçalanma, oradayken bir sınama hak eder, çünkü bağlanıp ardından büyük aktarımlarda takılan bir tünel genellikle kapalı bir bağlantı noktası değil, yanlış bir MTU'ya sahiptir:

ping -M do -s 1400 203.0.113.10
ping -M do -s 1372 203.0.113.10

Windows'ta aynı sınama ping -f -l 1400 203.0.113.10. Tünelin MTU'sunu geçen en büyük boyutun altına ayarlayın, ardından başarısız aktarımı yeniden sınayın.

Bir plan için ödeme yapmadan önce üç satırı doğrulayın

Üç satırı tek bir sayfaya koyun ve her hücreyi bir vaat yerine ölçülmüş sonuçla doldurun. Bu komutlar o sayfanın yerel yarısını yaklaşık bir dakikada üretir:

ss -lntup | sort
nc -vz -w 3 203.0.113.10 443
python3 -m http.server 8080 --bind 0.0.0.0
curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080
ping -M do -s 1400 203.0.113.10

Çıktıyı bir denetim listesi olarak okuyun. Tünel açıkken hedef yanıt verdiğinde giden çalışır. Gelen yalnızca ağınızın dışındaki bir ana makine dış bağlantı noktasındaki dinleyiciye ulaştığında çalışır. Taşıyıcı, erişim ağınızın izin verdiği bir protokolde el sıkışma tamamlandığında çalışır.

İki alışkanlık sayfayı dürüst tutar. Her sonucun yanına tarihi ve istemci sürümünü yazın, çünkü hem sağlayıcı politikaları hem de istemci varsayılanları hareket eder. Ardından akışa hizmet eden en dar eşlemeyi isteyin, çünkü her şeyi açma talebi genellikle teknik bir yanıt yerine bir ret veya ek satış kazanır.