Nebula punchy-innstillinger: hvilken fikser NAT-en din

To peers finner hverandre gjennom fyrtårnet og klarer deretter ikke å bygge en direkte vei, og den første impulsen er å slå på hvert punchy-alternativ. Den impulsen gir en konfigurasjon med tre endringer og ingen anelse om hvilken som betydde noe. Innstillingene svarer på ulike spørsmål: én vedlikeholder en mapping som allerede finnes, og én prøver et håndtrykk i motsatt retning. Bestem hvilket spørsmål du har før du rører noen av dem.

Bekreft endepunktet før timingen

En peer som aldri dukker opp på den forventede adressen blir ikke reddet av punch-tuning. Sjekk hva fyrtårnet vet om peeren og hva peerens egen konfigurasjon annonserer, fordi en utdatert bootstrap-adresse eller en privat adresse publisert ved en feil ødelegger hvert gjennomtrengningstriks. Bekreft også at sertifikatet er klarert, siden en uklarert identitet stopper samtalen lenge før NAT betyr noe. Deretter må du bekrefte at UDP i det hele tatt når fyrtårnet. Tidsverdier er det siste man ser på, ikke det første.

Noter endepunktparet du tester med, slik at senere sammenligninger bruker de samme peerne og ikke to andre maskiner.

punch beholder en mapping, respond åpner en retning

punch-alternativet sender med jevne mellomrom tomme pakker til underlagsadressen til en peer som allerede har en tunnel. Formålet er ikke glamorøst: det hindrer en stateful NAT eller brannmur i å la mappingen den direkte veien avhenger av, utløpe. respond-alternativet endrer hva som skjer ved en fyrtårnsvarsling, og får verten til å prøve et håndtrykk tilbake mot peeren som prøver å nå den. Det er forskjellige mekanismer med forskjellige feilmåter.

Velg punch når den direkte veien virker og senere svekkes. Velg respond når veien aldri dannes i én retning. Å slå på begge og håpe er måten en femminutters rettelse blir en uke med tuning.

Forsinkelsene bestemmer når, ikke om

Forsinkelsesverdiene forskyver timingen: den ene gjelder pakken som sendes etter en varsling, den andre det omvendte håndtrykksforsøket. Ingen av dem gjør en blokkert retning fungerende. Å endre begge samtidig ødelegger sammenligningen du var i ferd med å gjøre.

La dem være i fred til mekanismen er riktig. Juster så én, og skriv ned den gamle verdien.

Når en relay er det ærlige svaret

Noen NAT-kombinasjoner kan ikke støtte en direkte vei, uansett hvordan timingen ordnes. Symmetrisk NAT på begge sider, eller en brannmur som slipper all uoppfordret innkommende trafikk, etterlater ingenting å punch gjennom.

En relay-node med en tilgjengelig adresse gir disse peerne en vei som ikke avhenger av at gjennomtrengningen lykkes. Det koster båndbredde gjennom den noden, så det er en beslutning om kapasitet og ikke en omvei. Konfigurer relayen bevisst og kontroller at peerne kan nå den, fordi en relay som selv står bak en vanskelig NAT ikke endrer noe. Slutt så å tune punch-innstillingene for det paret, siden den direkte veien aldri ville dukke opp.

Test paret som feilet, etter lediggang

Gjenskap betingelsen som brast: la paret stå ledig i samme intervall, eller gjenta håndtrykkssekvensen som pleide å feile. Prøv så applikasjonen mellom de to peerne, ikke en forespørsel til fyrtårnet. Et svar fra fyrtårnet beviser kontrollveien og ingenting om dataveien.

Noter hvilken innstilling som ble endret, tidspunktet, og om en direkte vei dukket opp eller trafikken ble værende på relayen. Ble den værende, er svaret en relay og et kapasitetsnotat, og det er et helt godt utfall. Dukket den opp, er neste spørsmål om den overlever en time med lediggang, fordi en mapping som svekkes er akkurat problemet punch finnes for.