VPN-portvereistes: drie reëls om te skryf voordat jy vergelyk

Portlyste vir VPN-dienste word tussen vergelykingsbladsye oorgedra sonder die besonderhede wat bepaal of hulle saak maak: wie die verbinding begin. ’n Reël wat uitgaande TCP 443 toelaat, sê niks daaroor of ’n ander gasheer ’n luisteraar op jou masjien kan bereik nie. Skryf drie afsonderlike vereistes voordat jy ’n enkele plan vergelyk, en merk watter een jou taak werklik nodig het. Die meeste vergelykings val saam in een kort vraag sodra daardie bladsy bestaan.

Deel die vereiste voordat jy enige portlys lees

Drie reëls dek byna elke geval: om ’n bestemming anderkant die tonnel te bereik, om iets te publiseer sodat ander kan inkom, en om die tonnel self te dra. Elke reël faal om ’n ander rede, en ’n diensverskaffer se beleid wat een bevredig, kan die ander twee onaangeraak laat. Om jou taak in die regte reël te sorteer neem vyf minute en spaar later ’n argument.

Bemarkingsstellings vervaag die drie reëls doelbewus. ’n P2P-toelating beskryf ’n bestemmingsbeleid, ’n toegewyde adres beskryf ’n adres, en ’n bewering van geen portbeperkings beteken gewoonlik dat die plan hulle nie opsom nie. Nie een van daardie frases beantwoord die ander nie.

Kies een konkrete vloei en skryf dit as ’n sin: inisieerder, transport, port, adresfamilie, rigting. ’n Nagtelike rugsteunkliënt wat na ’n afgeleë gasheer oplaai, is slegs uitgaande. ’n Speletjiebediener op jou lessenaar waarby vriende aansluit, is inkomend. Om albei deur een tonnel te laat loop, beteken die bladsy het albei reëls nodig, nie ’n kompromie tussen hulle nie.

Uitgaande toegang faal op bestemmingsbeleid, nie op die tonnel nie

Uitgaande verkeer deur ’n vertalende poort skep toestand. Die eerste pakket van ’n interne adres en port bou ’n vertalingsinskrywing, en antwoorde pas daarby, wat die karteringsgedrag is wat in RFC 3022 beskryf word. Daardie meganisme is waarom ’n blaaier-oortjie gewoonlik sonder enige portversoek werk.

Twee dinge breek dit steeds. Die uitgangsknoop kan bestemmings of portnommers filter wat dit as misbruikbaar beskou, en die toepassing kan luister op ’n port wat die uitgangsbeleid nooit verwag het nie. Vra oor die bestemmingspaar eerder as oor inkomende reëls, en verwag verskillende antwoorde vir TCP en UDP.

Meet voordat jy argumenteer. Voer hierdie uit op die masjien wat agter die tonnel sal sit, een keer met die tonnel af en een keer met dit op:

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

Dieselfde opdragte, dieselfde bestemming, twee tonneltoestande, gee ’n operateur ’n voor-en-na waarop hulle kan reageer. Vervang die dokumentasie-adres met die gasheer wat jy werklik nodig het; wat saak maak is dat die vergelyking herhaal word, nie dat enige nommer indrukwekkend lyk nie.

Inkomende publikasie benodig ’n kartering, ’n adres en ’n leeftyd

Niks buite kan ’n verbinding na jou luisteraar begin nie, tensy iets aan die publieke kant weet waarheen om dit te lewer. ’n Statiese portreservering wat die operateur hou, ’n kliëntversoekte kartering deur UPnP, NAT-PMP of PCP, en ’n gerouteerde publieke adres is drie verskillende produkte met drie verskillende beperkings.

Vra vyf vrae oor enige van hulle: watter protokol, watter eksterne port, of die eksterne port van die plaaslike een mag verskil, watter adresfamilie dit dek, en hoe lank die kartering ’n herverbinding oorleef. ’n Reservering wat aan ’n aktiewe sessie gekoppel is, verdwyn wanneer daardie sessie eindig, wat die planbladsy ook al sê.

Bevestig eers die plaaslike helfte, want ’n dooie luisteraar en ’n geblokkeerde inkomende pad lyk van buite identies:

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

Wanneer die plaaslike versoek 200 teruggee en ’n versoek van ’n netwerk wat jy nie beheer nie steeds tyd uitloop, sit die gaping aan die publieke kant. Dit is die oomblik om protokol en eksterne port aan die operateur te noem eerder as om die app by naam te beskryf.

Die tonnel se eie transport is ’n aparte vraag

Draerporte is die kleinste deel van die probleem en die maklikste om na te slaan. Verstekke verskil per protokol, en wat die kliënt kan onderhandel maak meer saak as enige planbeskrywing.

’n Netwerk wat uitgaande UDP laat val, sal ’n TCP 443-tonnel aanvaar en ’n UDP-een weier, so ’n terugvalmodus hoort op die vereisteblad. Om die draer te verander skuif nie ’n toepassingport binne die tonnel nie, en dit verbreed nie ’n bestemmingsbeleid nie; dié bly op hul eie reëls.

Fragmentasie verdien een toets terwyl jy daar is, want ’n tonnel wat verbind en dan op groot oordragte vasval, het gewoonlik die verkeerde MTU eerder as ’n geslote port:

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

Op Windows is dieselfde toets ping -f -l 1400 203.0.113.10. Stel die tonnel-MTU onder die grootste grootte wat deurkom, en hertoets dan die oordrag wat gefaal het.

Verifieer die drie reëls voordat jy vir ’n plan betaal

Sit die drie reëls op een bladsy en vul elke sel met ’n gemete resultaat eerder as ’n belofte. Hierdie opdragte lewer die plaaslike helfte van daardie bladsy in omtrent ’n minuut:

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

Lees die uitset as ’n kontrolelys. Uitgaande werk wanneer die bestemming antwoord met die tonnel op. Inkomend werk net wanneer ’n gasheer buite jou netwerk die luisteraar op die eksterne port bereik. Die draer werk wanneer die handskud voltooi op ’n protokol wat jou toegangsnetwerk toelaat.

Twee gewoontes hou die bladsy eerlik. Teken die datum en die kliëntweergawe by elke resultaat aan, want diensverskafferbeleid en kliëntverstekke beweeg albei. Vra dan om die nouste kartering wat die vloei dien, want ’n versoek om alles oop te maak verdien gewoonlik ’n weiering of ’n byverkoop eerder as ’n tegniese antwoord.