Nebula punchy-innstillingar: kva for ei løyser NAT-en din

To peers finn kvarandre gjennom fyrtårnet og klarer deretter ikkje å byggje ein direkte veg, og den første impulsen er å slå på kvart punchy-alternativ. Den impulsen gjev ein konfigurasjon med tre endringar og inga aning om kva for ei som betydde noko. Innstillingane svarar på ulike spørsmål: éi vedlikeheld ei mapping som alt finst, og éi prøver eit handtrykk i motsett retning. Bestem kva for eit spørsmål du har før du rører nokon av dei.

Stadfest endepunktet før timinga

Ein peer som aldri dukkar opp på den venta adressa vert ikkje redda av punch-tuning. Sjekk kva fyrtårnet veit om peeren og kva peerens eiga konfigurasjon annonserer, fordi ei utdatert bootstrap-adresse eller ei privat adresse publisert ved ein feil øydelegg kvart gjennomtrengingstriks. Stadfest òg at sertifikatet er klarert, sidan ein uklarert identitet stoggar samtalen lenge før NAT tyder noko. Deretter må du stadfeste at UDP i det heile når fyrtårnet. Tidsverdiar er det siste ein ser på, ikkje det første.

Noter endepunktparet du testar med, slik at seinare samanlikningar brukar dei same peerane og ikkje to andre maskinar.

punch held ein mapping, respond opnar ei retning

punch-alternativet sender med jamne mellomrom tomme pakkar til underlagsadressa til ein peer som alt har ein tunnel. Føremålet er ikkje glamorøst: det hindrar ein stateful NAT eller brannmur i å la mappinga den direkte vegen er avhengig av, gå ut på tid. respond-alternativet endrar kva som skjer ved ei fyrtårnsvarsling, og får verten til å prøve eit handtrykk tilbake mot peeren som prøver å nå han. Det er ulike mekanismar med ulike feilmåtar.

Vel punch når den direkte vegen verkar og seinare svekkjest. Vel respond når vegen aldri vert danna i éi retning. Å slå på begge og håpe er måten ein femminutts retting vert ei veke med tuning.

Forseinkingane avgjer når, ikkje om

Forseinkingsverdiane forskyv timinga: den eine gjeld pakken som vert send etter ei varsling, den andre det omvende handtrykksforsøket. Ingen av dei gjer ei blokkert retning verksam. Å endre begge samtidig øydelegg samanlikninga du var i ferd med å gjere.

Lat dei vere i fred til mekanismen er rett. Juster så éin, og skriv ned den gamle verdien.

Når ein relay er det ærlege svaret

Nokre NAT-kombinasjonar kan ikkje støtte ein direkte veg, uansett korleis timinga vert ordna. Symmetrisk NAT på begge sider, eller ein brannmur som slepp all uoppfordra innkommande trafikk, lèt ingenting att å punch gjennom.

Ein relay-node med ei tilgjengeleg adresse gjev desse peerane ein veg som ikkje er avhengig av at gjennomtrenginga lukkast. Det kostar bandbreidd gjennom den noden, så det er ei avgjerd om kapasitet og ikkje ein omveg. Konfigurer relayen medvite og kontroller at peerane kan nå han, fordi ein relay som sjølv står bak ein vanskeleg NAT ikkje endrar noko. Slutt så å tune punch-innstillingane for det paret, sidan den direkte vegen aldri ville dukke opp.

Test paret som feila, etter lediggang

Gjenskap vilkåret som braut: lat paret stå ledig i same intervall, eller gjer om att handtrykkssekvensen som pleidde å feile. Prøv så applikasjonen mellom dei to peerane, ikkje ein førespurnad til fyrtårnet. Eit svar frå fyrtårnet provar kontrollvegen og ingenting om datavegen.

Noter kva for ei innstilling som vart endra, tidspunktet, og om ein direkte veg dukka opp eller trafikken vart verande på relayen. Vart han verande, er svaret ein relay og eit kapasitetsnotat, og det er eit heilt godt utfall. Dukka han opp, er neste spørsmål om han overlever ein time med lediggang, fordi ei mapping som svekkjest er nettopp problemet punch finst for.