Setările punchy din Nebula: care îți repară NAT-ul

Doi peers se găsesc prin far și apoi nu reușesc să construiască o cale directă, iar primul instinct este să activezi fiecare opțiune punchy. Acel instinct produce o configurație cu trei modificări și fără nicio idee care dintre ele conta. Setările răspund la întrebări diferite: una întreține o mapare care există deja, iar cealaltă încearcă un handshake în direcția inversă. Decide ce întrebare ai înainte de a atinge vreuna dintre ele.

Confirmă punctul final înainte de timing

Un peer care nu apare niciodată la adresa așteptată nu va fi salvat de reglajul punch. Verifică ce știe farul despre peer și ce anunță configurația lui, pentru că o adresă bootstrap învechită sau o adresă privată publicată din greșeală anulează orice truc de traversare. Confirmă și că certificatul este de încredere, fiindcă o identitate neîncrezută oprește conversația mult înainte ca NAT-ul să conteze. Apoi verifică dacă UDP ajunge măcar la far. Valorile de timp sunt ultimul lucru la care te uiți, nu primul.

Notează perechea de puncte finale cu care testezi, ca mai târziu comparațiile să folosească aceiași peers și nu alte două mașini.

punch păstrează o mapare, respond deschide o direcție

Opțiunea punch trimite periodic pachete goale către adresa de nivel inferior a unui peer care are deja un tunel. Scopul nu este fastuos: împiedică un NAT cu stare sau un firewall să lase să expire maparea de care depinde calea directă. Opțiunea respond schimbă ce se întâmplă la o notificare a farului, făcând gazda să încerce un handshake înapoi către peerul care încearcă să o atingă. Sunt mecanisme diferite cu moduri de eșec diferite.

Alege punch când calea directă funcționează și apoi slăbește. Alege respond când calea nu se formează niciodată într-o direcție. Să le activezi pe amândouă și să speri este modul în care o reparație de cinci minute devine o săptămână de reglaje.

Întârzierile decid când, nu dacă

Valorile de întârziere deplasează momentul: una se aplică pachetului trimis după o notificare, cealaltă încercării de handshake invers. Niciuna nu face o direcție blocată să funcționeze. Schimbarea ambelor deodată distruge comparația pe care urma să o faci.

Lasă-le în pace până când mecanismul este corect. Apoi ajustează unul și notează valoarea veche.

Când un releu este răspunsul onest

Unele combinații de NAT nu pot susține o cale directă, oricum ar fi aranjat timpul. NAT simetric pe ambele părți, sau un firewall care aruncă complet traficul de intrare nesolicitat, nu lasă nimic de străpuns.

Un nod releu cu o adresă accesibilă le dă acelor peers o cale care nu depinde de succesul traversării. Costă lățime de bandă prin acel nod, deci este o decizie despre capacitate, nu o soluție de ocol. Configurează releul în mod deliberat și verifică dacă peers îl pot atinge, fiindcă un releu care este el însuși în spatele unui NAT dificil nu schimbă nimic. Apoi oprește reglarea setărilor punch pentru acea pereche, fiindcă calea directă nu avea să apară niciodată.

Testează perechea care a eșuat, după inactivitate

Reproduce condiția care s-a stricat: lasă perechea inactivă același interval, sau repetă secvența de handshake-uri care eșua înainte. Apoi exersează aplicația între acei doi peers, nu o cerere către far. Un răspuns al farului dovedește calea de control și nimic despre calea de date.

Notează ce setare s-a schimbat, ora și dacă a apărut o cale directă sau traficul a rămas pe releu. Dacă a rămas, răspunsul este un releu și o notă despre capacitate, și este un rezultat perfect bun. Dacă a apărut, următoarea întrebare este dacă supraviețuiește o oră de inactivitate, fiindcă o mapare care slăbește este exact problema pentru care există punch.