Nebulas punchy-inställningar: vilken fixar din NAT

Två peers hittar varandra via fyren och lyckas sedan inte bygga en direkt väg, och den första impulsen är att slå på varje punchy-alternativ. Den impulsen ger en konfiguration med tre ändringar och ingen aning om vilken som spelade roll. Inställningarna svarar på olika frågor: en underhåller en mappning som redan finns, och en försöker ett handslag i motsatt riktning. Bestäm vilken fråga du har innan du rör någon av dem.

Bekräfta ändpunkten före timingen

En peer som aldrig dyker upp på den förväntade adressen räddas inte av punch-tuning. Kontrollera vad fyren vet om peeren och vad peerens egen konfiguration annonserar, eftersom en inaktuell bootstrap-adress eller en privat adress som publicerats av misstag omintetgör varje genomträngningstrick. Bekräfta också att certifikatet är betrott, eftersom en obetrodd identitet stoppar samtalet långt innan NAT spelar någon roll. Kontrollera sedan att UDP ens når fyren. Tidsvärden är det sista man tittar på, inte det första.

Anteckna ändpunktsparet du testar med, så att senare jämförelser använder samma peers och inte två andra maskiner.

punch behåller en mappning, respond öppnar en riktning

Alternativet punch skickar med jämna mellanrum tomma paket till underlagsadressen för en peer som redan har en tunnel. Syftet är inte glamoröst: det hindrar en stateful NAT eller brandvägg från att låta mappningen som den direkta vägen hänger på gå ut. Alternativet respond ändrar vad som händer vid en fyrnotis, och får värden att försöka ett handslag tillbaka mot peeren som försöker nå den. Det är olika mekanismer med olika felsätt.

Välj punch när den direkta vägen fungerar och senare försvagas. Välj respond när vägen aldrig bildas i en riktning. Att slå på båda och hoppas är hur en femminutersfix blir en vecka av tuning.

Fördröjningarna avgör när, inte om

Fördröjningsvärdena förskjuter timingen: den ena gäller paketet som skickas efter en notis, den andra det omvända handslagsförsöket. Ingen av dem gör en blockerad riktning fungerande. Att ändra båda samtidigt förstör jämförelsen du var på väg att göra.

Låt dem vara i fred tills mekanismen är rätt. Justera sedan en, och skriv ner det gamla värdet.

När en relay är det ärliga svaret

Vissa NAT-kombinationer kan inte stödja en direkt väg, hur timingen än ordnas. Symmetrisk NAT på båda sidor, eller en brandvägg som helt kastar oombedd inkommande trafik, lämnar inget att puncha igenom.

En relay-nod med en nåbar adress ger de peerarna en väg som inte beror på att genomträngningen lyckas. Det kostar bandbredd genom den noden, så det är ett beslut om kapacitet och inte en omväg. Konfigurera relayen medvetet och kontrollera att peerarna kan nå den, eftersom en relay som själv står bakom en svår NAT inte ändrar något. Sluta sedan tuna punch-inställningarna för det paret, eftersom den direkta vägen aldrig skulle dyka upp.

Testa paret som misslyckades, efter inaktivitet

Återskapa villkoret som gick sönder: låt paret stå inaktivt under samma intervall, eller upprepa handslagssekvensen som brukade misslyckas. Öva sedan applikationen mellan de två peerarna, inte en förfrågan till fyren. Ett svar från fyren bevisar kontrollvägen och ingenting om datavägen.

Anteckna vilken inställning som ändrades, tiden, och om en direkt väg dök upp eller trafiken stannade på relayen. Stannade den, är svaret en relay och en kapacitetsnotering, och det är ett helt bra resultat. Dök den upp, är nästa fråga om den överlever en timmes inaktivitet, eftersom en mappning som försvagas är precis problemet som punch finns för.