Ajustes punchy de Nebula: cuál arregla tu NAT

Dos pares se encuentran a través del faro y luego no logran construir una ruta directa, y el primer instinto es activar todas las opciones punchy. Ese instinto produce una configuración con tres cambios y ninguna idea de cuál importaba. Los ajustes responden preguntas distintas: uno mantiene una asignación que ya existe, y otro intenta un handshake en la dirección inversa. Decide qué pregunta tienes antes de tocar cualquiera de los dos.

Confirma el extremo antes del tiempo

Un par que nunca aparece en la dirección esperada no se salvará con el ajuste de punch. Revisa qué sabe el faro sobre el par y qué anuncia su propia configuración, porque una dirección bootstrap obsoleta o una dirección privada publicada por error anula todo truco de atravesado. Confirma también que el certificado es de confianza, ya que una identidad no confiable detiene la conversación mucho antes de que la NAT importe. Luego verifica que UDP llegue siquiera al faro. Los valores de tiempo son lo último que hay que mirar, no lo primero.

Anota el par de extremos con el que pruebas, para que las comparaciones posteriores usen los mismos pares y no otras dos máquinas.

punch conserva una asignación, respond abre una dirección

La opción punch envía periódicamente paquetes vacíos a la dirección de capa inferior de un par que ya tiene un túnel. Su propósito no es vistoso: evita que una NAT con estado o un cortafuegos caduque la asignación de la que depende la ruta directa. La opción respond cambia lo que ocurre en una notificación del faro, haciendo que el host intente un handshake de vuelta hacia el par que intenta alcanzarlo. Son mecanismos distintos con modos de fallo distintos.

Elige punch cuando la ruta directa funciona y luego decae. Elige respond cuando la ruta nunca se forma en una dirección. Activar ambos y esperar es cómo una reparación de cinco minutos se convierte en una semana de ajustes.

Los retardos deciden cuándo, no si

Los valores de retardo desplazan el momento: uno se aplica al paquete enviado tras una notificación, el otro al intento de handshake inverso. Ninguno hace funcionar una dirección bloqueada. Cambiar ambos a la vez destruye la comparación que estabas a punto de hacer.

Déjalos en paz hasta que el mecanismo sea el correcto. Luego ajusta uno, y anota el valor antiguo.

Cuando un relé es la respuesta honesta

Algunas combinaciones de NAT no pueden soportar una ruta directa por mucho que se ordene el tiempo. Una NAT simétrica en ambos lados, o un cortafuegos que descarta por completo el tráfico entrante no solicitado, no dejan nada que perforar.

Un nodo relé con una dirección alcanzable da a esos pares una ruta que no depende de que el atravesado tenga éxito. Cuesta ancho de banda por ese nodo, así que es una decisión sobre capacidad y no un rodeo. Configura el relé a propósito y comprueba que los pares pueden alcanzarlo, porque un relé que está él mismo detrás de una NAT difícil no cambia nada. Luego deja de ajustar los parámetros de punch para ese par, ya que la ruta directa nunca iba a aparecer.

Prueba el par que falló, tras dejarlo inactivo

Reproduce la condición que se rompió: deja el par inactivo el mismo intervalo, o repite la secuencia de handshake que antes fallaba. Luego ejercita la aplicación entre esos dos pares, no una petición al faro. Una respuesta del faro demuestra la ruta de control y nada sobre la ruta de datos.

Anota qué ajuste cambió, la hora, y si apareció una ruta directa o el tráfico se quedó en el relé. Si se quedó, la respuesta es un relé y una nota de capacidad, y es un resultado perfectamente bueno. Si apareció, la siguiente pregunta es si sobrevive una hora de inactividad, porque una asignación que decae es exactamente el problema para el que existe punch.