Publique un porto de cliente VPN detrás de CGNAT: lista de verificación

Pon un servizo nun portátil detrás de NAT de nivel de operador, apunta ese portátil a un VPS por unha VPN e ninguén de fóra pode alcanzalo. Engades unha regra NAT de destino no VPS e obtés algo peor que o silencio: as conexións abren e logo atascan. A resposta non falta, está saíndo pola ruta predeterminada do propio cliente, o que significa que o servidor nunca a ve. Percorre estas cinco comprobacións en orde e detente na primeira que non se cumpra.

Confirma que o servidor reenviará sequera

Marca esta caixa antes de escribir unha soa tradución. O analizador de regras acepta unha regra DNAT para un paquete que o núcleo se nega a reenviar e despois a ruta de reenvío descártao, o que produce un tempo de espera que parece un problema de cortalumes.

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

Establecelo nun núcleo en execución non é o mesmo que establecelo entre reinicios. Escribe net.ipv4.ip_forward=1 nun ficheiro baixo /etc/sysctl.d/, executa sysctl --system e despois volve ler o valor en lugar de confiar en que o ficheiro se recolleu. Un contedor que xestiona o seu propio espazo de nomes de rede necesita o mesmo valor dentro dese espazo, non só no anfitrión.

Se a lectura segue a ser cero, detente aquí. Nada máis abaixo funcionará.

Fixa o enderezo do túnel antes de que ningunha regra o mencione

O grupo reparte enderezos en orde de conexión, así que unha regra escrita para o arrendamento de hoxe pode apuntar en silencio a outro cliente a semana que vén. Ata o enderezo á identidade do certificado en lugar de á orde de chegada.

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

Ese par é o extremo do cliente e o extremo do par dun túnel punto a punto, co servidor ligado ao nome común do certificado. Nunha topoloxía de subrede o segundo valor lese como máscara de rede, así que escribe a forma que coincida coa topoloxía en uso. Despois reconecta o cliente e le o enderezo no propio cliente, porque a visión do servidor sobre o grupo non é proba do que configurou o cliente.

Se o enderezo cambia tras unha reconexión, detente. Unha regra NAT que segue un obxectivo móbil fallará de forma intermitente e non che ensinará nada.

Traduce en ambos os sentidos

A tradución de destino envía o paquete entrante ao cliente. A tradución de orixe é o que fai que o cliente responda ao servidor e non ao remitente orixinal, e é a regra que a xente 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

Sen a segunda regra o cliente responde pola súa ligazón ascendente do ISP, así que o par remoto ve un enderezo de orixe co que nunca falou, mentres o servidor non garda ningunha entrada de seguimento para a resposta. O observador externo ve un saúdo que se completa a medias, e ese é exactamente o síntoma que manda a xente buscar un fallo de cortalumes que non existe.

Volve ler ambas as regras con iptables -t nat -S e confirma que o nome da interface é o que leva o enderezo público. Nun anfitrión que xa filtra con nftables, escribe a tradución nunha cadea NAT de nftables da familia de enderezos correspondente en lugar de mesturar ferramentas.

Deixa pasar a táboa de filtros

As táboas NAT reescriben cabeceiras; non conceden permiso. Cunha política DROP predeterminada o fluxo reenviado necesita a súa propia aceptación, máis a dirección de retorno que a maioría das políticas xa cobren cunha regra 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

Comproba a política da cadea FORWARD antes de engadir nada, porque a orde dun DROP temperán decide se a túa regra chega a consultarse. Nun anfitrión cuxa filtración vive en nftables, engade a regra equivalente ao gancho forward da táboa inet e confirma que a cadea base ve realmente o tráfico reenviado e non só a entrada local. Se un contador de paquetes da regra nova queda en cero mentres os contadores de NAT soben, o paquete estase descartando antes da túa regra. Esa é a sinal para ler a orde das cadeas, non para engadir unha segunda copia da mesma regra.

Proba desde unha rede externa

Proba desde unha rede non relacionada. Unha sonda desde outra máquina na mesma LAN pode pasar polo soporte de NAT de horquilla e nunca exercitar a ruta que usa un cliente remoto, así que un resultado verde alí demostra o equivocado.

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

Executa a captura no servidor e no cliente ao mesmo tempo. A captura do servidor mostra se o paquete traducido sae cara ao túnel; a captura do cliente mostra se a solicitude chega e onde se dirixe a resposta. Unha entrada de tradución en conntrack -L demostra que a regra coincidiu, e a súa ausencia demostra que o paquete nunca chegou á cadea NAT.

Os escáneres de portos son probas débiles. Informan do porto como pechado ata que a aplicación está ligada e escoitando, así que usa unha conexión real ao servizo real. Cando por fin funcione, mantén a exposición nese único porto: reenviar SSH ou un panel de administración porque a primeira regra resultaba incómoda é unha decisión moito maior que publicar un servizo.