Axustes punchy de Nebula: cal arranxa o teu NAT

Dous pares atópanse a través do faro e despois non conseguen construír unha ruta directa, e o primeiro instinto é activar todas as opcións punchy. Ese instinto produce unha configuración con tres cambios e ningunha idea de cal importaba. Os axustes responden preguntas distintas: un mantén unha asignación que xa existe, e outro tenta un handshake na dirección inversa. Decide que pregunta tes antes de tocar calquera dos dous.

Confirma o extremo antes do tempo

Un par que nunca aparece no enderezo esperado non se salvará co axuste de punch. Revisa que sabe o faro sobre o par e que anuncia a súa propia configuración, porque un enderezo bootstrap obsoleto ou un enderezo privado publicado por erro anula todo truco de atravesamento. Confirma tamén que o certificado é de confianza, xa que unha identidade non confiable detén a conversa moito antes de que o NAT importe. Despois verifica que UDP chega sequera ao faro. Os valores de tempo son o último que hai que mirar, non o primeiro.

Anota o par de extremos co que probas, para que as comparacións posteriores usen os mesmos pares e non outras dúas máquinas.

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

A opción punch envía periodicamente paquetes baleiros ao enderezo de capa inferior dun par que xa ten un túnel. O seu propósito non é vistoso: evita que un NAT con estado ou un cortafogos caduque a asignación da que depende a ruta directa. A opción respond cambia o que ocorre nunha notificación do faro, facendo que o host tente un handshake de volta cara ao par que intenta alcanzalo. Son mecanismos distintos con modos de fallo distintos.

Escolle punch cando a ruta directa funciona e despois decae. Escolle respond cando a ruta nunca se forma nunha dirección. Activar ambos e esperar é como unha reparación de cinco minutos se converte nunha semana de axustes.

Os atrasos deciden cando, non se

Os valores de atraso desprazan o momento: un aplícase ao paquete enviado tras unha notificación, o outro ao intento de handshake inverso. Ningún fai funcionar unha dirección bloqueada. Cambiar ambos á vez destrúe a comparación que estabas a piques de facer.

Déixaos en paz ata que o mecanismo sexa o correcto. Logo axusta un, e anota o valor antigo.

Cando un relé é a resposta honesta

Algunhas combinacións de NAT non poden soportar unha ruta directa por moito que se ordene o tempo. Un NAT simétrico en ambos os dous lados, ou un cortafogos que descarta por completo o tráfico entrante non solicitado, non deixan nada que perforar.

Un nodo relé cun enderezo alcanzable dá a eses pares unha ruta que non depende de que o atravesamento teña éxito. Custa ancho de banda por ese nodo, así que é unha decisión sobre capacidade e non unha volta. Configura o relé a propósito e comproba que os pares poden alcanzalo, porque un relé que está el mesmo detrás dun NAT difícil non cambia nada. Logo deixa de axustar os parámetros de punch para ese par, xa que a ruta directa nunca ía aparecer.

Proba o par que fallou, tras deixalo inactivo

Reproduce a condición que se rompeu: deixa o par inactivo o mesmo intervalo, ou repite a secuencia de handshake que antes fallaba. Logo exercita a aplicación entre eses dous pares, non unha petición ao faro. Unha resposta do faro demostra a ruta de control e nada sobre a ruta de datos.

Anota que axuste cambiou, a hora, e se apareceu unha ruta directa ou o tráfico quedou no relé. Se quedou, a resposta é un relé e unha nota de capacidade, e é un resultado perfectamente bo. Se apareceu, a seguinte pregunta é se sobrevive unha hora de inactividade, porque unha asignación que decae é exactamente o problema para o que existe punch.