OpenVPN de túnel completo: engada unha saída a internet no lado do servidor

Un cliente autentícase, recibe un enderezo do conxunto e chega aos servizos do host VPN, pero todo destino público remata en tempo esgotado. Así se ve un túnel sen saída, e así segue ata que se cumpren catro cousas distintas. O cliente debe aceptar unha ruta predeterminada, o servidor debe reenviar, o cortalumes debe permitir o tránsito e as respostas necesitan un camiño de volta ao conxunto. As catro fallas comparten un só síntoma, así que cambie un elemento por intento e anote o resultado.

Empurre a ruta predeterminada e confirme que instalou o cliente

A liña do lado do servidor é curta, e só afecta os clientes que aceptan opcións empurradas. A forma def1 instala dúas rutas medio predeterminadas en lugar de borrar a predeterminada existente, o que mantén viva a conexión actual e á vez captura todos os destinos.

push "redirect-gateway def1"

Tras reconectar, lea a táboa de rutas do cliente en lugar de confiar no perfil. En Linux as dúas entradas /1 aparecen xunto á ruta predeterminada orixinal, e Windows mostra o mesmo par como 0.0.0.0/1 e 128.0.0.0/1. Un cliente que ignora as opcións empurradas, ou un configurado para rexeitalas, conserva a súa vella ruta predeterminada e nunca envía tráfico de internet ao túnel. Resolva esa cuestión antes de cambiar nada no servidor, porque ningunha regra do lado do servidor pode compensalo.

O reenvío é un axuste do servidor, non do VPN

Lea o indicador de reenvío antes de tocar o encamiñamento. Un cero alí significa que o núcleo recibe o paquete do cliente e négase a pasalo, o que parece exactamente un bloqueo do cortalumes desde o extremo remoto. Fixe o valor a través do directorio de configuración do sistema para que sobreviva a un reinicio.

sysctl net.ipv4.ip_forward
echo 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-vpn-forward.conf
sudo sysctl --system

A continuación, confirme que o propio host ten unha ruta funcional cara á saída a internet. Unha petición desde a consola do servidor demostra que a ruta ascendente é utilizable e non di absolutamente nada sobre reenviar o paquete dun cliente, así que tráteas como dúas probas separadas. Se o servidor non pode alcanzar o destino, ningunha cantidade de configuración de reenvío axudará.

Permita o tránsito que pretende, e nada máis

Os paquetes reenviados cruzan a ruta forward; o tráfico dirixido ao propio host VPN cruza input. Son decisións distintas, e abrir a ruta input non permite o tránsito pola máquina. Confundilas é a razón máis común de que un cortalumes pareza permitilo todo mentres os clientes seguen esgotando o tempo.

Unha política mínima acepta conexións novas do conxunto cara á interface de saída e acepta as respostas que pertencen a fluxos establecidos. Póñaao no propietario de conxunto de regras que use a súa distribución, en lugar de engadir unha regra duplicada en cada arranque; as regras duplicadas acumúlanse e os contadores deixan de significar nada.

sudo iptables -A FORWARD -i tun0 -o eth0 -s 10.90.0.0/24 -j ACCEPT
sudo iptables -A FORWARD -i eth0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Cambiar cada cadea a aceptar fai que a proba pase e elimina a razón de existir do cortalumes. Manteña o alcance no conxunto e na interface de saída, e deixe en paz o reenvío non relacionado.

Dea ás respostas un lugar ao que ir

Os enderezos do conxunto son privados, así que un servidor público non pode entregarlles unha resposta directamente. Ou o host VPN traduce o enderezo de orixe á saída, ou un dispositivo augas arriba mantén unha ruta de volta ao conxunto.

sudo iptables -t nat -A POSTROUTING -s 10.90.0.0/24 -o eth0 -j MASQUERADE

Engada exactamente unha capa de tradución. Un segundo NAT máis arriba oculta o primeiro e fai que ambos os rexistros sexan case inútiles cando algo se rompe despois. Se un router augas arriba xa encamiña o conxunto de volta, engadir tradución no host é redundante, e o camiño de volta depende entón da configuración dese router e non da súa.

As instancias na nube engaden unha porta máis, porque algunhas plataformas descartan paquetes cuxo enderezo de orixe non é o da instancia salvo que se relaxe esa comprobación. Ese axuste está fóra do convidado e é fácil de esquecer cando unha máquina de proba local funciona.

Demostre que funciona desde o cliente, non desde a consola do servidor

Comece cunha petición IPv4 numérica, logo unha consulta de nome, logo a aplicación. Un ping demostra o reenvío e a tradución;non demostra nada sobre a resolución, porque as opcións de DNS só surten efecto cando a integración do cliente as instala.

curl -4 -m 5 http://198.51.100.10/
dig +short example.com

Anote os cambios e o paso de desfacer sobre a marcha, para que a política de saída se poida reverter nunha soa acción cando unha proba falla. Esta receita só cobre IPv4; faga inventario de IPv6 por separado antes de afirmar que o despregamento transporta todo o tráfico.