Disparo de portos fronte a reenvío de portos para un servidor VPN doméstico

O reenvío de portos e o disparo de portos están no mesmo menú na maioría dos routers domésticos, e por iso trátanse como dúas formas de facer un mesmo traballo. O reenvío é unha regra estática: unha conexión entrante a un porto WAN tradúcese a un enderezo e un porto internos fixos, ocorra ou non outra cousa. O disparo é condicional: o router vixía o tráfico de saída e só abre unha asignación entrante despois de que saia unha conexión coincidente. Un servidor VPN espera que outro se conecte primeiro, así que esa condición é xusto o único que nunca pode cumprir.

Dúas regras con ciclos de vida distintos

A NAT de IPv4 ten estado. Cando un equipo interno envía un paquete cara a fóra, o router crea unha asignación para que as respostas atopen o camiño de volta; un paquete entrante que non coincide con ningunha asignación descártase, e ese é o comportamento que mantén un escritorio sen actualizar fóra de internet. O reenvío é unha entrada de tradución permanente engadida a man. O disparo é un burato temporal vixiado por un patrón de tráfico.

A diferenza práctica é o tempo. Un reenvío existe desde que se garda ata que alguén o borra. Unha asignación disparada existe despois de que o disparador se active e péchase cun temporizador de inactividade, medido en minutos en hardware de consumo, ou de inmediato ao reiniciar.

Ningún dos dous é máis seguro en abstracto. Un reenvío expón un porto de forma continua; un disparador expono só tras certo tráfico de saída. Para un servizo que debe aceptar o primeiro paquete dun descoñecido, só un dos dous encaixa co traballo.

Por que o disparo non publicará un servidor

Un servidor VPN é pasivo por deseño. O par, sexa un portátil nunha cafetería ou un móbil con datos móbiles, envía o primeiro paquete, e o router non ten ningunha asignación para el. Nada dentro iniciou tráfico cara ao porto do disparador, así que a regra nunca se activa e a conexión morre antes de que comece o handshake.

Onde o disparo parece funcionar, algo máis xera tráfico no porto do disparador: un cliente na LAN, unha sonda de monitorización ou as propias comprobacións de saída do servidor. Entón a asignación ábrese para ese único equipo e péchase cando o tráfico se detén, así que o seguinte par externo volve fallar mentres o primeiro éxito queda no rexistro como se fose unha proba.

O disparo tamén adoita ser dun só equipo. Moitas implementacións permiten que só un dispositivo interno teña a asignación á vez, o cal é exactamente o incorrecto para un servidor que debe responder a varios pares. A función creouse para aplicacións que abren unha conexión de control cara a fóra e esperan datos entrantes nun segundo porto, e segue encaixando nesa forma.

Que asigna realmente un reenvío

Un reenvío é unha entrada de tradución: porto WAN e protocolo cara a enderezo e porto internos. Necesita un oínte que xa se execute no outro extremo, e necesita que o enderezo interno quede onde está. Unha concesión DHCP que se traslada a outra máquina envía cada túnel ao equipo equivocado, en silencio, así que cree a reserva antes da regra.

O protocolo importa máis do que suxire o formulario. OpenVPN sobre UDP necesita un reenvío UDP, WireGuard necesita UDP, e os datos de IPsec chegan como ESP, protocolo IP 50, que non ten ningún porto. Un formulario de reenvío que só acepta TCP ou UDP non pode expresar iso, así que IPsec necesita passthrough ou unha asignación estática un a un en lugar dunha regra de porto.

A capa por riba do seu router

Un reenvío só controla a tradución que é súa. Se o enderezo WAN non é seu, que é o caso detrás dunha NAT de operador onde os subscritores comparten 100.64.0.0/10 como se describe en RFC 6598, a conexión entrante nunca chega ao seu router porque o provedor traduciu primeiro. Ningunha regra no seu dispositivo pode arranxar esa orde.

A NAT dobre é o mesmo problema en miniatura. O seu router reenvía ao router do ISP, que non ten ningunha regra coincidente e descarta o paquete. Ou engade a regra no dispositivo exterior, ou pon o dispositivo exterior en modo ponte e deixa que o seu teña o enderezo público.

Por iso a proba ten que vir de fóra. Unha proba desde a mesma LAN a través do enderezo público depende do soporte de hairpin NAT e pode pasar ou fallar por motivos alleos á regra; un móbil con datos móbiles, ou un amigo noutra rede, é a comprobación máis limpa.

Delimite a regra e logo verifique as dúas metades

Reenvíe un porto a un enderezo. Un rango engadido porque os primeiros intentos fallaron é como as interfaces de xestión acaban en internet, e o oínte de VPN non necesita a páxina de administración do router publicada ao lado.

Conserve todo o que xa protexía ese oínte: identidade por certificado ou chave, cortalumes do equipo, versións actuais dos paquetes. Un reenvío deixa entrar un paquete; a autenticación decide se o paquete se converte en túnel, e son dous fallos separados cando algo vai mal.

A verificación ten dúas metades. O handshake debe completarse desde unha rede externa, e despois un recurso privado detrás do servidor debe responder polo túnel. O reenvío admite a conexión do túnel e nada máis; o encamiñamento e a autorización para 10.8.0.0/24 son outro axuste noutra pantalla.

Decida con tres preguntas

Tres preguntas resolven a elección máis rápido ca calquera táboa comparativa:

• Conecta algo desde fóra como primeiro paquete? Entón use reenvío, ou un relé. O disparo non pode abrirse sen un tráfico de saída que nunca existirá.
• Debe o burato sobrevivir ao tempo de inactividade? Entón use reenvío, porque unha asignación disparada péchase segundo o seu propio calendario.
• O enderezo WAN é seu para publicalo? Se non o é, arranxe a capa de arriba antes de editar calquera regra.

Se a resposta ás tres é non, que é o caso dun portátil que marca por si mesmo un provedor comercial, non fai falta ningunha das dúas regras. Un cliente detrás de NAT funciona porque crea el mesmo a asignación con estado, e iso cobre a maioría de quen le unha páxina de reenvío de portos á medianoite.