Que portos VPN abrir nun firewall: protocolo por protocolo

Dúas regras separadas deciden se un túnel VPN sobrevive a un firewall: o porto ao que marca o cliente e o protocolo que transporta a carga. Abre só a primeira e o túnel autenticarase, pero despois non moverá ningún dato. O mínimo é un porto TCP máis GRE para PPTP, dous portos UDP máis ESP para L2TP/IPsec e IKEv2, e un único porto para SSTP, OpenVPN e WireGuard. A dirección, o seguimento de estado e o NAT deciden o resto.

Comeza polo porto ao que marca o cliente

Cada familia ten un punto de entrada ao que o cliente contacta primeiro, e ese punto de entrada é o que a túa regra de permiso debe nomear. Os clientes PPTP conéctanse a TCP 1723. L2TP/IPsec inicia IKE en UDP 500 e pasa a UDP 4500 cando se usa a travesía de NAT, coa propia trama L2TP en UDP 1701 dentro do túnel. SSTP envolve a sesión en TLS sobre TCP 443, IKEv2 negocia en UDP 500 e 4500, OpenVPN usa UDP 1194 por defecto pero a miúdo móvese a TCP 443, e WireGuard escoita en UDP 51820.

Trata eses números como valores por defecto e non como propiedades fixas. Unha interface WireGuard usa o porto de escoita que declare a súa configuración, e un servidor OpenVPN pode estar en calquera porto que escollese o administrador. Le a configuración do servidor antes de escribir a regra, porque un firewall aberto para 1194 non fai nada por un servidor que se moveu a 443.

A terceira columna é onde fallan a maioría dos tíckets de cambio. A regra existe, pero apunta ao destino equivocado, á dirección equivocada ou ao transporte equivocado.

GRE e ESP son números de protocolo, non portos

GRE e ESP non teñen ningún porto, así que un formulario de firewall que só acepta números de porto non pode expresalos. GRE é o protocolo IP 47 e ESP é o protocolo IP 50, ambos se emparellan mediante o campo de protocolo da cabeceira IP. Unha regra escrita como porto TCP 47 non coincide con nada, e así unha política PPTP parece correcta e aínda así descarta cada paquete despois do apretón de mans.

Os routers domésticos esconden isto tras unha caixa de paso que instala a regra de protocolo e, para GRE, o axudante de NAT necesario para mapear o fluxo. Nun firewall real engades o protocolo ti mesmo: permite o protocolo IP 47 cara ao servidor PPTP, permite o protocolo IP 50 cara á pasarela IPsec. Onde a plataforma non ofrece campo de protocolo, a encapsulación é a saída, por iso IKEv2 pode recaer en UDP 4500 e por iso OpenVPN e WireGuard nunca atopan o problema.

Comproba con que coincide realmente a regra antes de culpar o cliente. Un contador de paquetes que queda en cero na pasarela di que a regra nunca se activou, e ningunha cantidade de reinstalación no lado do cliente o cambia.

A dirección, o estado e o NAT cambian a resposta

Un cliente que marca cara a fóra e unha pasarela que escoita cara a dentro son requisitos distintos, e a mesma lista de portos pode ser correcta nunha dirección e incorrecta na outra. Un firewall con estado segue o fluxo UDP en 500 e 4500 e deixa volver as respostas sen unha segunda regra. ESP e GRE non levan portos, así que un dispositivo NAT non ten de que agarrarse e necesita un axudante ou unha encapsulación para seguir a sesión.

A travesía de NAT é a parte que se pasa por alto. IKEv2 comeza en UDP 500, detecta un dispositivo NAT e continúa en UDP 4500, así que unha política que só permite 500 dá un túnel que se establece e despois cala. L2TP/IPsec fai o mesmo movemento. Se a túa captura mostra o primeiro intercambio pero non tráfico sostido, busca unha regra que se deteña en 500.

Anota a dirección con cada regra. «Permitir UDP 4500» non significa nada ata que digas de onde a onde, e unha regra correcta para un cliente itinerante adoita ser incorrecta para un par sitio a sitio.

Comproba cada camiño cunha captura

Executa a captura na pasarela, non no cliente: un cliente só rexistra o que chegou. Estes filtros cobren as familias anteriores e mostran que etapa falta:

sudo tcpdump -ni any tcp port 1723
sudo tcpdump -ni any udp port 500 or udp port 4500
sudo tcpdump -ni any proto gre
sudo tcpdump -ni any proto 50

Le a saída como unha secuencia. Cando aparece a negociación pero non o protocolo de carga, o descarte ocorre nalgún punto entre o cliente e a pasarela. Cando aparecen ambos e a páxina segue fallando, o firewall xa non é o sospeitoso; mira o encamiñamento, o DNS ou o conxunto de enderezos entregado ao cliente.

Nunha máquina sen tcpdump, a mesma evidencia vén dos contadores de interface e de regras. Bytes que entran pero non saen na interface do túnel apuntan ao camiño de volta e non á regra de permiso inicial.

Deixa un conxunto de regras que poidas defender

SSTP sobre TCP 443 é indistinguible dun HTTPS corrente para calquera filtro baseado en portos, e ese é o punto cando unha rede só permite tráfico web. Tamén é a razón de que a regra do 443 deba nomear a pasarela como destino en lugar de todo internet. Borra as regras temporais de calquera-a-calquera en canto o túnel funcione. Anota que regra coincidiu, o número de protocolo onde o haxa e a dirección, para que a seguinte persoa comece con evidencia.

As pasarelas de nube de punto a sitio fan visible a escolla: o perfil descargado usa ou SSTP en 443 ou IKEv2 en 500 e 4500, e deberías abrir só o que o perfil elixa de verdade. PPTP non merece a excepción de GRE nunha rede moderna, xa que as operadoras móbiles adoitan descartar o protocolo 47 independentemente do teu firewall. Antes de pechar o tícket, confirma que a regra coincide co porto da configuración do servidor, que o campo de protocolo está posto onde a familia o necesita e que o destino é a pasarela e non calquera enderezo.