Nebula punchy-indstillinger: hvilken løser din NAT

To peers finder hinanden gennem fyrtårnet og formår derefter ikke at bygge en direkte vej, og den første indskydelse er at tænde hver punchy-mulighed. Den indskydelse giver en konfiguration med tre ændringer og ingen idé om, hvilken der betød noget. Indstillingerne besvarer forskellige spørgsmål: én vedligeholder en mapping, der allerede findes, og én forsøger et handshake i den modsatte retning. Afgør, hvilket spørgsmål du har, før du rører nogen af dem.

Bekræft endepunktet før timingen

En peer, der aldrig dukker op på den forventede adresse, bliver ikke reddet af punch-tuning. Undersøg, hvad fyrtårnet ved om peeren, og hvad peerens egen konfiguration annoncerer, fordi en forældet bootstrap-adresse eller en privat adresse offentliggjort ved en fejl ødelægger ethvert gennemtrængningstrick. Bekræft også, at certifikatet er betroet, da en ubetroet identitet stopper samtalen længe før NAT betyder noget. Bekræft derefter, at UDP overhovedet når fyrtårnet. Tidsværdier er det sidste, man ser på, ikke det første.

Notér det endepunktspar, du tester med, så senere sammenligninger bruger de samme peers og ikke to andre maskiner.

punch beholder en mapping, respond åbner en retning

punch-muligheden sender med jævne mellemrum tomme pakker til underlagsadressen på en peer, der allerede har en tunnel. Dens formål er uglamourøst: den forhindrer en stateful NAT eller firewall i at lade den mapping udløbe, som den direkte vej afhænger af. respond-muligheden ændrer, hvad der sker ved en fyrtårnsnotifikation, så værten forsøger et handshake tilbage mod den peer, der prøver at nå den. Det er forskellige mekanismer med forskellige fejlmåder.

Vælg punch, når den direkte vej virker og senere svækkes. Vælg respond, når vejen aldrig dannes i én retning. At tænde begge og håbe er måden, hvorpå en femminutters rettelse bliver en uges tuning.

Forsinkelserne bestemmer hvornår, ikke om

Forsinkelsesværdierne flytter timingen: den ene gælder pakken, der sendes efter en notifikation, den anden det omvendte handshake-forsøg. Ingen af dem gør en blokeret retning fungerende. At ændre begge på én gang ødelægger den sammenligning, du var ved at lave.

Lad dem være, indtil mekanismen er rigtig. Justér derefter én, og skriv den gamle værdi ned.

Når en relay er det ærlige svar

Nogle NAT-kombinationer kan ikke understøtte en direkte vej, uanset hvordan timingen arrangeres. Symmetrisk NAT i begge ender, eller en firewall der helt dropper uopfordret indgående trafik, efterlader intet at punch igennem.

Et relay-knudepunkt med en tilgængelig adresse giver de peers en vej, der ikke afhænger af, at gennemtrængningen lykkes. Det koster båndbredde gennem det knudepunkt, så det er en beslutning om kapacitet snarere end en omvej. Konfigurér relayen bevidst og kontrollér, at peerne kan nå den, fordi en relay, der selv står bag en vanskelig NAT, ikke ændrer noget. Hold derefter op med at tune punch-indstillingerne for det par, da den direkte vej aldrig ville opstå.

Test det par, der fejlede, efter lediggang

Genskab den betingelse, der brød: lad parret være ledigt i samme interval, eller gentag den handshake-sekvens, der plejede at fejle. Prøv derefter applikationen mellem de to peers, ikke en forespørgsel til fyrtårnet. Et svar fra fyrtårnet beviser kontrolvejen og intet om datavejen.

Notér hvilken indstilling der blev ændret, tidspunktet, og om en direkte vej opstod, eller trafikken blev på relayen. Hvis den blev, er svaret en relay og en kapacitetsnote, og det er et ganske godt resultat. Hvis den opstod, er det næste spørgsmål, om den overlever en times lediggang, fordi en mapping, der svækkes, netop er det problem, punch findes for at løse.