Publique un puerto de cliente VPN detrás de CGNAT: lista de comprobación

Ponga un servicio en un portátil detrás de NAT de nivel de operador, apunte ese portátil a un VPS por una VPN y nadie de fuera podrá alcanzarlo. Añade una regla NAT de destino en el VPS y obtiene algo peor que el silencio: las conexiones se abren y luego se atascan. La respuesta no falta, está saliendo por la ruta predeterminada del propio cliente, lo que significa que el servidor nunca la ve. Recorra estas cinco comprobaciones en orden y deténgase en la primera que no se cumpla.

Confirme que el servidor reenviará siquiera

Marque esta casilla antes de escribir una sola traducción. El analizador de reglas acepta una regla DNAT para un paquete que el núcleo se niega a reenviar y luego la ruta de reenvío lo descarta, lo que produce un tiempo de espera que parece un problema de cortafuegos.

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1

Establecerlo en un núcleo en ejecución no es lo mismo que establecerlo entre reinicios. Escriba net.ipv4.ip_forward=1 en un archivo bajo /etc/sysctl.d/, ejecute sysctl --system y luego vuelva a leer el valor en lugar de confiar en que el archivo se haya recogido. Un contenedor que gestiona su propio espacio de nombres de red necesita el mismo valor dentro de ese espacio, no solo en el anfitrión.

Si la lectura sigue siendo cero, deténgase aquí. Nada más abajo funcionará.

Fije la dirección del túnel antes de que ninguna regla la mencione

El grupo reparte direcciones en orden de conexión, así que una regla escrita para el arrendamiento de hoy puede apuntar en silencio a otro cliente la semana que viene. Ate la dirección a la identidad del certificado en lugar de al orden de llegada.

client-config-dir /etc/openvpn/ccd
ifconfig-push 10.77.0.14 10.77.0.13

Ese par es el extremo del cliente y el extremo del par de un túnel punto a punto, con el servidor vinculado al nombre común del certificado. En una topología de subred el segundo valor se lee como máscara de red, así que escriba la forma que coincida con la topología en uso. Después reconecte el cliente y lea la dirección en el propio cliente, porque la visión del servidor sobre el grupo no es prueba de lo que configuró el cliente.

Si la dirección cambia tras una reconexión, deténgase. Una regla NAT que sigue a un objetivo móvil fallará de forma intermitente y no le enseñará nada.

Traduzca en ambos sentidos

La traducción de destino envía el paquete entrante al cliente. La traducción de origen es lo que hace que el cliente responda al servidor y no al remitente original, y es la regla que la gente omite.

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 29443 -j DNAT --to-destination 10.77.0.14:29443
iptables -t nat -A POSTROUTING -d 10.77.0.14 -p tcp --dport 29443 -j SNAT --to-source 10.77.0.13

Sin la segunda regla el cliente responde por su enlace ascendente del ISP, así que el par remoto ve una dirección de origen con la que nunca habló, mientras el servidor no guarda ninguna entrada de seguimiento para la respuesta. El observador externo ve un saludo que se completa a medias, y ese es exactamente el síntoma que manda a la gente a buscar un fallo de cortafuegos que no existe.

Vuelva a leer ambas reglas con iptables -t nat -S y confirme que el nombre de la interfaz es el que lleva la dirección pública. En un anfitrión que ya filtra con nftables, escriba la traducción en una cadena NAT de nftables de la familia de direcciones correspondiente en lugar de mezclar herramientas.

Deje pasar la tabla de filtros

Las tablas NAT reescriben cabeceras; no conceden permiso. Con una política DROP predeterminada el flujo reenviado necesita su propia aceptación, más la dirección de retorno que la mayoría de las políticas ya cubren con una regla established,related.

iptables -A FORWARD -i eth0 -o tun0 -p tcp --dport 29443 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Compruebe la política de la cadena FORWARD antes de añadir nada, porque el orden de un DROP temprano decide si su regla llega a consultarse. En un anfitrión cuya filtración vive en nftables, añada la regla equivalente al enganche forward de la tabla inet y confirme que la cadena base ve realmente el tráfico reenviado y no solo la entrada local. Si un contador de paquetes de la regla nueva se queda en cero mientras los contadores de NAT suben, el paquete se está descartando antes de su regla. Esa es la señal para leer el orden de las cadenas, no para añadir una segunda copia de la misma regla.

Pruébelo desde una red externa

Pruebe desde una red no relacionada. Una sonda desde otra máquina en la misma LAN puede pasar por el soporte de NAT de horquilla y no ejercitar nunca la ruta que usa un cliente remoto, así que un resultado verde allí demuestra lo equivocado.

tcpdump -ni any port 29443
conntrack -L | grep 29443

Ejecute la captura en el servidor y en el cliente al mismo tiempo. La captura del servidor muestra si el paquete traducido sale hacia el túnel; la captura del cliente muestra si la solicitud llega y dónde se dirige la respuesta. Una entrada de traducción en conntrack -L demuestra que la regla coincidió, y su ausencia demuestra que el paquete nunca llegó a la cadena NAT.

Los escáneres de puertos son pruebas débiles. Informan del puerto como cerrado hasta que la aplicación está vinculada y escuchando, así que use una conexión real al servicio real. Cuando por fin funcione, mantenga la exposición en ese único puerto: reenviar SSH o un panel de administración porque la primera regla resultaba incómoda es una decisión mucho mayor que publicar un servicio.