VPN de sitio a sitio fronte a acceso remoto: que une cada un

Ambos deseños chámanse VPN e resolven problemas distintos. Un túnel de sitio a sitio une dúas pasarelas, de xeito que cada host detrás delas pode alcanzar as direccións permitidas do outro lado sen instalar nada. Un túnel de acceso remoto une dispositivos individuais a unha rede, un cliente á vez. A comparación importa porque a maioría dos erros de despregamento proveñen de configurar un deseño esperando o comportamento do outro, e o síntoma adoita ser un tempo de espera esgotado nun servizo ao que o túnel si chegou.

Dous deseños, dúas fronteiras

Ningún dos dous deseños estende un dominio de difusión LAN. Os dispositivos do lado remoto non aparecen nunha lista de descuberta local, e esperar que o fagan é a primeira suposición que hai que abandonar. Os nomes DNS privados que publica a propósito son máis previsibles que calquera protocolo de descuberta e sobreviven a un cambio de provedor.

Tome 10.10.0.0/24 nun sitio e 10.20.0.0/24 no outro. A pasarela A necesita unha ruta ou un selector de tráfico que envíe o prefixo 10.20.0.0/24 ao túnel, e a pasarela B necesita a imaxe espello. Os hosts de ambos os lados usan entón conectividade IP corrente e nunca chegan a saber que existe un túnel. Esa invisibilidade é a característica, e tamén é a razón pola que os fallos parecen erros de rede ordinarios en lugar de erros de túnel.

Baseado en política e baseado en ruta non son o mesmo túnel

Nun despregamento de IPsec baseado en política, os selectores de tráfico negociados definen exactamente que pares de orixe e destino están protexidos. Se aparece unha subrede nova detrás dunha pasarela e ningún selector a cobre, o túnel segue activo e a subrede nova simplemente non se transporta. Nun deseño baseado en ruta, unha interface recibe o tráfico e a táboa de encamiñamento decide, o que fai que engadir un prefixo sexa un cambio de encamiñamento e non unha renegociación do túnel.

StrongSwan expón ambas as vistas directamente, e lelas xuntas é como se averigua que modelo despregou en realidade.

swanctl --list-sas
ip xfrm policy
ip -4 route show table all | grep -E '10\.(10|20)\.'

Unha lista de selectores que omite o prefixo que lle importa explica o fallo sen ningunha captura de paquetes, e unha ruta que apunta á interface equivocada explica o fallo espello de volta. Lea ambas as cousas antes de renegociar nada, porque unha renovación de chave non engadirá un selector que nunca configurou.

Planifique o direccionamento antes do túnel

Os rangos solapados son o erro de deseño que non se pode corrixir con configuración. Se ambos os sitios usan 192.168.1.0/24, un host que necesita 192.168.1.50 ten dous candidatos e ningunha forma de escoller. O túnel autenticarase, as asociacións de seguridade estableceranse e a decisión de encamiñamento será errónea ou ambigua de todos os xeitos.

Escolla unha de tres opcións honestas: renumerar un sitio, traducir o rango solapado na pasarela para que cada lado vexa un prefixo distinto, ou renunciar ao encamiñamento directo para eses hosts e publicar o servizo doutro xeito. Cada unha ten un custo, e a primeira adoita ser a máis barata nun horizonte de dous anos. Decida antes de que exista o túnel, porque despois o cambio toca todos os dispositivos que teñan a dirección antiga.

Resolva tamén a cuestión da MTU pronto. Un túnel reduce a carga útil, e un deseño que depende da fragmentación compórtase de forma distinta a un que fixa a MSS nas pasarelas.

O reenvío e a política quedan fóra do túnel

A pasarela debe estar disposta a reenviar paquetes entre a interface do túnel e a interface LAN, e ambas as direccións necesitan unha política que permita o servizo. En Linux son dous axustes separados, máis as regras da devasa que deciden se o fluxo reenviado se permite sequera.

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -s 10.20.0.0/24 -d 10.10.0.0/24 -j ACCEPT
iptables -A FORWARD -s 10.10.0.0/24 -d 10.20.0.0/24 -j ACCEPT

O host receptor engade unha terceira capa: o seu propio devasa aínda ten que aceptar un cliente da subrede remota. Un servidor de ficheiros que só permite o seu /24 local rexeitará o tráfico reenviado desde 10.20.0.7, por moi san que pareza o túnel, e ese rexeitamento lese facilmente como un fallo de encamiñamento.

Probe desde un host, non desde a pasarela

Un ping orixinado pola propia pasarela pode seguir unha dirección de orixe e unha política distintas das do tráfico de usuario reenviado. Iso convérteo nunha proba feble e, ás veces, enganosa: ten éxito mentres a aplicación falla, ou falla mentres a aplicación funciona.

ip route get 10.10.0.5 from 10.20.0.7
ping -I 10.20.0.7 10.10.0.5
curl -sv --max-time 5 http://files.10-10.internal/ -o /dev/null

Use un host real, unha dirección de orixe real e o protocolo real que utiliza a aplicación. Despois lea o camiño de volta por separado, porque unha dirección de ida que funciona sen ruta de retorno produce un tempo de espera esgotado que parece idéntico ao dun servizo bloqueado.

Escolla o deseño segundo a pregunta que responde: está unindo redes ou admitindo dispositivos? Todo o demais, incluído que provedor configura, derívase desa resposta.