Paràmetres punchy de Nebula: quin arregla la teva NAT

Dos parells es troben a través del far i després no aconsegueixen construir un camí directe, i el primer instint és activar totes les opcions punchy. Aquest instint produeix una configuració amb tres canvis i cap idea de quin va ser el que importava. Els paràmetres responen preguntes diferents: un manté un mapatge que ja existeix, i un altre intenta un handshake en la direcció inversa. Decidiu quina pregunta teniu abans de tocar cap dels dos.

Confirmeu el punt final abans del moment

Un parell que no apareix mai a l'adreça esperada no es rescatarà amb l'ajust de punch. Reviseu què sap el far sobre el parell i què anuncia la seva pròpia configuració, perquè una adreça bootstrap obsoleta o una adreça privada publicada per error desactiva qualsevol truc de travessa. Confirmeu també que el certificat és de confiança, ja que una identitat no confiable atura la conversa molt abans que la NAT importi. Després verifiqueu que UDP arriba al far. Els valors de temps són l'últim que cal mirar, no el primer.

Anoteu la parella de punts finals amb què proveu, perquè les comparacions posteriors facin servir els mateixos parells i no dues màquines altres.

punch conserva un mapatge, respond obre una direcció

L'opció punch envia periòdicament paquets buits a l'adreça de capa inferior d'un parell que ja té un túnel. El seu propòsit no és glamurós: evita que una NAT amb estat o un tallafoc faci caducar el mapatge del qual depèn el camí directe. L'opció respond canvia què passa en una notificació del far, fent que l'amfitrió intenti un handshake de tornada cap al parell que intenta arribar-hi. Són mecanismes diferents amb maneres de fallar diferents.

Trieu punch quan el camí directe funciona i després decau. Trieu respond quan el camí no es forma mai en una direcció. Activar tots dos i esperar és com una reparació de cinc minuts es converteix en una setmana d'ajustos.

Els retards decideixen quan, no si

Els valors de retard desplacen el moment: un s'aplica al paquet enviat després d'una notificació, l'altre a l'intent de handshake invers. Cap dels dos fa funcionar una direcció blocada. Canviar tots dos alhora destrueix la comparació que estàveu a punt de fer.

Deixeu-los estar fins que el mecanisme sigui correcte. Després ajusteu-ne un, i anoteu el valor antic.

Quan un relé és la resposta honesta

Algunes combinacions de NAT no poden suportar un camí directe per molt que s'ordeni el moment. Una NAT simètrica als dos costats, o un tallafoc que descarta del tot el trànsit entrant no sol·licitat, no deixen res per foradar.

Un node relé amb una adreça arribable dona a aquests parells un camí que no depèn de l'èxit de la travessa. Costa amplada de banda per aquell node, així que és una decisió sobre capacitat i no una solució alternativa. Configureu el relé deliberadament i comproveu que els parells hi poden arribar, perquè un relé que és ell mateix darrere una NAT difícil no canvia res. Després deixeu d'ajustar els paràmetres punch per a aquesta parella, ja que el camí directe no havia d'aparèixer mai.

Proveu la parella que va fallar, després d'inactivitat

Reproduïu la condició que es va trencar: deixeu la parella inactiva el mateix interval, o repetiu la seqüència de handshake que abans fallava. Després exerciteu l'aplicació entre aquests dos parells, no una petició al far. Una resposta del far demostra el camí de control i res sobre el camí de dades.

Anoteu quin paràmetre va canviar, l'hora, i si va aparèixer un camí directe o el trànsit es va quedar al relé. Si s'hi va quedar, la resposta és un relé i una nota de capacitat, i és un resultat perfectament bo. Si va aparèixer, la pregunta següent és si sobreviu una hora d'inactivitat, perquè un mapatge que decau és exactament el problema per al qual existeix punch.