Nebula punchy-instellingen: welke lost je NAT op

Twee peers vinden elkaar via de vuurtoren en slagen er daarna niet in een direct pad op te bouwen, en de eerste impuls is elke punchy-optie aanzetten. Die impuls levert een configuratie met drie wijzigingen op en geen idee welke ervan ertoe deed. De instellingen beantwoorden verschillende vragen: de ene onderhoudt een mapping die al bestaat, en de andere probeert een handshake in de omgekeerde richting. Bepaal welke vraag je hebt voordat je een van beide aanraakt.

Bevestig het eindpunt vóór de timing

Een peer die nooit op het verwachte adres verschijnt, wordt niet gered door punch-tuning. Controleer wat de vuurtoren over de peer weet en wat diens eigen configuratie aankondigt, want een verouderd bootstrap-adres of een privéadres dat per ongeluk is gepubliceerd maakt elke doorkruisingstruc ongedaan. Bevestig ook dat het certificaat vertrouwd is, want een niet-vertrouwde identiteit stopt het gesprek lang voordat NAT ertoe doet. Controleer daarna of UDP de vuurtoren überhaupt bereikt. Tijdwaarden zijn het laatste waar je naar kijkt, niet het eerste.

Noteer het eindpuntpaar waarmee je test, zodat latere vergelijkingen dezelfde peers gebruiken en niet twee andere machines.

punch houdt een mapping vast, respond opent een richting

De punch-optie stuurt periodiek lege pakketten naar het underlay-adres van een peer die al een tunnel heeft. Het doel is niet glorieus: het houdt een stateful NAT of firewall ervan af de mapping te laten verlopen waar het directe pad van afhangt. De respond-optie verandert wat er bij een vuurtorenmelding gebeurt, waardoor de host een handshake terug probeert naar de peer die hem probeert te bereiken. Dat zijn verschillende mechanismen met verschillende faalwijzen.

Kies punch wanneer het directe pad werkt en later wegvalt. Kies respond wanneer het pad zich nooit in één richting vormt. Beide aanzetten en hopen is hoe een oplossing van vijf minuten een week tuning wordt.

De vertragingen bepalen wanneer, niet of

De vertragingswaarden verschuiven de timing: de ene geldt voor het pakket dat na een melding wordt verzonden, de andere voor de omgekeerde handshakepoging. Geen van beide maakt een geblokkeerde richting werkend. Beide tegelijk wijzigen vernietigt de vergelijking die je op het punt stond te maken.

Laat ze met rust tot het mechanisme klopt. Stel er dan één bij, en schrijf de oude waarde op.

Wanneer een relay het eerlijke antwoord is

Sommige NAT-combinaties kunnen geen direct pad ondersteunen, hoe de timing ook is geregeld. Symmetrische NAT aan beide kanten, of een firewall die ongevraagd inkomend verkeer volledig weggooit, laat niets over om doorheen te prikken.

Een relay-node met een bereikbaar adres geeft die peers een pad dat niet afhangt van het slagen van de doorkruising. Het kost bandbreedte via die node, dus het is een beslissing over capaciteit en geen omweg. Configureer de relay bewust en controleer dat de peers hem kunnen bereiken, want een relay die zelf achter een lastige NAT staat verandert niets. Stop daarna met het tunen van de punch-instellingen voor dat paar, want het directe pad zou nooit verschijnen.

Test het paar dat faalde, na inactiviteit

Reproduceer de omstandigheid die brak: laat het paar dezelfde periode inactief, of herhaal de handshake-reeks die vroeger faalde. Oefen daarna de toepassing tussen die twee peers, niet een verzoek aan de vuurtoren. Een antwoord van de vuurtoren bewijst het controlepad en niets over het datapad.

Noteer welke instelling veranderde, het tijdstip, en of er een direct pad verscheen of het verkeer op de relay bleef. Bleef het, dan is het antwoord een relay en een capaciteitsnotitie, en dat is een heel goed resultaat. Verscheen het, dan is de volgende vraag of het een uur inactiviteit overleeft, want een mapping die wegvalt is precies het probleem waarvoor punch bestaat.