Mascarada ou encamiñamento por políticas: tráfico LAN por unha pasarela VPN

Pór toda unha LAN detrás dun túnel VPN é a parte fácil; decidir como ve o lado remoto eses clientes non o é. A mascarada reescribe cada fonte da LAN ao enderezo do túnel da pasarela, de xeito que o extremo remoto responde a un só par. O encamiñamento por políticas conserva os enderezos orixinais e esixe que o extremo remoto saiba como chegar a eles. Ningunha das dúas é a opción predeterminada; a elección depende de quen posúe o lado remoto e de se importa a identidade por dispositivo.

Os dous deseños prometen cousas distintas

A mascarada reduce a LAN a un único host visible: a pasarela. A rede remota responde a ese único enderezo, e a pasarela traduce as respostas de volta ao cliente que iniciou o fluxo. Non se necesita ningunha ruta aos teus prefixos privados no lado remoto, e por iso este deseño sobrevive a un provedor que se nega a transportalos. A pasarela tamén se converte na fonte de cada conexión, así que o lado remoto non pode distinguir dous clientes.

O encamiñamento por políticas mantén intacto o enderezo de cada cliente. A rede remota ve a fonte real e pode rexistrala, aplicar unha regra por host ou enviar a resposta directamente a ese enderezo. Esa visibilidade é todo o obxectivo, e vén cunha obriga: o lado remoto debe ter unha ruta para o prefixo da LAN que apunte de volta polo túnel. Planifica esa ruta antes de activar a regra, porque o túnel se levantará de todos os xeitos e só faltarán as respostas.

Os modos de fallo difiren tanto como as promesas. Unha regra de mascarada ausente produce paquetes que saen con orixes privadas e nunca volven. Unha ruta de retorno ausente produce o mesmo síntoma co encamiñamento por políticas, pero a corrección pertence ao router remoto e non á pasarela.

Mascarada: un só par no lado remoto

A ruta da mascarada ten unha orde que importa. O reenvío debe estar activado antes de que ningunha regra NAT sirva de algo, a táboa de filtrado debe permitir o tránsito en ambos os sentidos, e só entón se aplica a tradución na interface do túnel.

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i eth1 -o tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

Os clientes seguen necesitando un camiño cara á pasarela. Ou a pasarela é o seu router predeterminado, ou levan unha ruta específica para o prefixo remoto; se un router separado segue sendo o predeterminado, ese router necesita unha ruta estática para os destinos do túnel, doutro xeito o paquete vai ao salto equivocado antes de que a pasarela o vexa.

O DNS é unha decisión á parte. Un resolutor do lado remoto só responde se a súa resposta pode viaxar de volta ao cliente. Con mascarada a consulta parece vir da pasarela, así que a ruta de retorno do resolutor xa está cuberta; con encamiñamento por políticas o resolutor necesita a mesma ruta de retorno que calquera outro servizo remoto.

Encamiñamento por políticas: conserva a orixe, engade unha ruta de retorno

O encamiñamento por políticas comeza cunha táboa e unha regra que a selecciona. O tráfico que entra pola interface da LAN envíase a unha táboa dedicada, e esa táboa leva unha ruta predeterminada polo túnel. A táboa principal queda intacta, así que o tráfico orixinado pola propia pasarela pode seguir outro camiño.

ip rule add iif eth1 table vpn
ip route add default dev tun0 table vpn

O lado remoto debe entón encamiñar o prefixo da LAN de volta polo túnel. Iso é unha configuración no router remoto, non nesta pasarela. A pasarela tamén debe aceptar respostas que chegan por unha interface distinta da que prevería a táboa principal; o filtrado laxo de ruta inversa (rp_filter axustado a 2) é o axuste habitual cando o modo estrito descarta eses paquetes.

Cando hai dous túneles activos, etiqueta cada fluxo ao entrar e deixa que a etiqueta escolla a táboa. Unha regra que só mira a interface de entrada envía o tráfico de ambos os túneles á mesma táboa, así que o segundo túnel rouba fluxos ao primeiro. Proba esa etiqueta cunha conexión que sobreviva a unha reconexión, que é cando se manifesta unha política mixta.

Decide por propiedade e polo que rexistra o lado remoto

Se o túnel remata nun provedor, usa mascarada. Ese operador non vai encamiñar os teus rangos privados de LAN, e non ten motivo para distinguir clientes individuais detrás da túa pasarela. Un só par visible é o único modelo que admite a súa política, así que dálle iso e mantén a tradución na túa beira. O provedor ve un par, que é exactamente o que espera a súa política, e os teus clientes herdan esa única identidade.

Se ambos os extremos son teus e os servizos remotos actúan sobre enderezos de orixe, o encamiñamento por políticas gaña a súa ruta adicional. As regras do cortafuegos, o acceso por usuario e os rexistros de auditoría poden entón distinguir clientes. Se o lado remoto só necesita alcanzabilidade, a mascarada é máis simple e elimina unha clase de erros de ruta de retorno.

Os deseños híbridos son normais: encamiñamento por políticas dentro da túa propia rede, mascarada na beira do provedor. O importante é anotar que salto traduce e que salto encamiña, porque unha regra NAT accidental engadida para un cliente oculta a orixe para todos os clientes da mesma cadea.

Verifica desde un cliente e logo desde un segundo cliente

Executa a proba onde comeza o tráfico. Comproba a ruta que usa o host, observa como o paquete aparece na interface do túnel e inspecciona conntrack para a tradución. Esa secuencia demostra que o paquete tomou o camiño previsto e non que simplemente chegou a algún sitio.

Repite a proba tras unha reconexión. Unha regra de mascarada que nomea a interface sobrevive a un novo enderezo de túnel; unha regra que nomea o enderezo antigo non. Despois proba un segundo host da LAN, porque un deseño que funciona nunha máquina a miúdo depende da ruta propia desa máquina e non da política da pasarela.

Anota o modelo elixido, a orixe traducida ou conservada e o propietario da ruta de retorno nas notas da pasarela. Se non, a seguinte persoa que engada un cliente ou un túnel adivinará, e adiviñar é como unha configuración LAN-a-VPN que funciona se volve parcial.