Por que a túa LAN non chega a un servizo nun cliente VPN

Un cliente VPN pode aloxar un servizo que a LAN non pode abrir. O que adoita faltar é o camiño de volta: unha ruta, un par de DNAT ou a liña SNAT que ninguén engade.

O teu túnel está activo, o servizo escoita e a LAN da oficina segue sen recibir nada de volta. Ninguén rompeu a VPN. Desde o lado da LAN, o enderezo de túnel do portátil non existe ata que algo lle di á LAN como chegar a el, e a resposta ten que volver polo mesmo camiño polo que saíu a petición. Vin xente reconstruír tres veces un túnel perfectamente bo antes de que alguén mirase o camiño de volta.

O túnel non é o que se rompeu

Os dous extremos están en rangos privados, que é o caso normal e non unha mala configuración. Un enderezo como 10.8.0.6 é real dentro do túnel e inexistente en calquera outro sitio, así que a LAN non ten motivo para lle enviar nada. Antes de tocar o encamiñamento, confirma que o servizo é accesible dentro do túnel: no cliente, ss -ltn mostra se o oínte se liga a 127.0.0.1, á interface da LAN ou ao enderezo do túnel. Un demo ligado só a loopback non responde a ninguén máis que a si mesmo, e ningunha ruta, DNAT ou redirección de porto o cambia.

Un proxy no porto 80 ou 443 é outra ferramenta con outra visibilidade. Move peticións, non paquetes, así que é a capa equivocada para unha conexión directa a unha base de datos, e recorrer a el é como este problema acaba tres ferramentas máis adentro antes de que alguén mida algo.

Forma de ruta: dille á LAN onde está o conxunto

Unha ruta estática na porta de enlace da LAN é a resposta máis limpa cando a LAN e o conxunto do túnel non se solapan. Apunta o conxunto á máquina que termina o túnel:

ip route add 10.8.0.0/24 via 192.168.1.12
route add -p 10.8.0.0 mask 255.255.255.0 192.168.1.12   # Windows, persistent

Iso arranxa só unha dirección, e por iso as versións a medias deste cambio parecen progreso. O lado do túnel necesita a metade correspondente, ou a resposta sae do cliente pola súa propia ruta por defecto e morre polo camiño:

push "route 192.168.1.0 255.255.255.0"

Para unha subrede que está detrás dun cliente en lugar de detrás do servidor, o servidor necesita tanto unha ruta de sistema como unha entrada iroute no ficheiro dese cliente baixo client-config-dir. Sen iroute, OpenVPN sabe que o prefixo existe e non ten idea de que cliente é o seu dono: os paquetes chegan e o demo non ten con que emparellalos.

Aquí está o mito que merece un nome. Unha ruta fai que un enderezo sexa alcanzable; non fai que o outro lado estea disposto a responder. Os pares sitio a sitio engaden outra capa enriba, porque a porta remota só acepta orixes dentro dos prefixos da súa política, e un portátil que chega dun conxunto doméstico non está dentro deles.

Forma NAT: DNAT cara a dentro e a liña SNAT que todos omiten

Cando non podes tocar a porta de enlace da LAN, ou queres publicar exactamente un porto, a tradución no host VPN funciona sen ningunha ruta na LAN. Publica o porto, rediríxeo e traduce a orixe de camiño ao túnel:

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8080 -j DNAT --to-destination 10.8.0.6:3000
iptables -A FORWARD -i eth0 -o tun0 -p tcp -d 10.8.0.6 --dport 3000 -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -d 10.8.0.6 -p tcp --dport 3000 -j SNAT --to-source 10.8.0.1

A terceira liña é a que desaparece. Omítea e o cliente ve o enderezo orixinal da LAN como orixe, responde pola súa propia ruta por defecto, e esa resposta vaise ao túnel en lugar de volver cara á LAN. Se a conexión sobrevive depende entón dun encamiñamento que nunca planificaches. Con SNAT o cliente ve o enderezo de túnel do servidor, así que a resposta segue o túnel de volta ao único host que pode desfacer a tradución.

O firmware de consumo usa os seus propios nomes de cadea e non xera esa tradución por ti. En Tomato, unha regra de entrada cae en WANPREROUTING e despois nunha cadea de filtrado como wanin, e un conxunto de regras que parece completo aínda necesita unha liña POSTROUTING manual. Iso non é un fallo do firmware; é un conxunto de regras escrito só para tráfico de entrada.

Por que unha regra que parece correcta segue descartando o paquete

A maioría destes fallos non están na regra que estás mirando. Comproba catro cousas nesta orde e detente na primeira que non se cumpra:

  • Orde das cadeas. iptables -I insire arriba e -A engade ao final, así que unha regra permisiva ou bloqueante anterior decide primeiro.
  • Cadea equivocada. O tráfico dirixido ao propio router pasa por INPUT, e o tráfico reenviado nunca o toca. Publicar un só servizo pode necesitar regras en ambas.
  • Bandeiras de dirección. -i tun0 coincide co tráfico que chega dos clientes e -o tun0 co que sae cara a eles. Un REJECT coa bandeira equivocada bloquea algo que non pretendías.
  • Restrición de orixe. Unha redirección que acepta un enderezo de cliente funciona desde ese cliente e descarta calquera outra orixe sen dicir nada.

Unha regra cun contador de paquetes a cero non está no camiño en absoluto, e ler os contadores é a forma máis rápida de separar un problema de cadea equivocada dun de regra equivocada.

A redirección local, cando nada na LAN pode cambiar

Unha redirección SSH local esquiva toda a cuestión. Non necesita ruta na LAN, nin cooperación do cortafogos do cliente, nin ningún porto publicado en ningures:

ssh -N -f -L 3000:10.8.0.6:3000 user@vpn-host

O servizo aparece entón en localhost:3000 da máquina que mantén o túnel, e en ningún outro sitio. Ese é o límite: unha estación de traballo, un porto, e a redirección morre coa sesión salvo que algo a reinicie. Para un administrador que comproba unha base de datos de probas é a ferramenta correcta. Para unha cámara ou un escáner ao que outras persoas teñen que chegar, non o é, porque cada usuario necesitaría a súa propia redirección.

Verifica as dúas direccións antes de engadir outra regra

A tradución deixa rastros, e lelos é mellor que adiviñar. No host VPN, conntrack -L mostra se a tradución ocorreu, iptables -t nat -L -n -v mostra se os contadores se moveron e tcpdump -ni any port 3000 mostra que enderezo de orixe chegou realmente. No cliente, ss -ltn confirma que o oínte está nun enderezo que o túnel pode alcanzar.

Despois escolle a forma que vas conservar. Un porto publicado, unha ruta para todo o conxunto e unha redirección para un só administrador son tres compromisos distintos, e mesturalos é como unha configuración que funciona se converte nunha que ninguén saberá explicar seis meses despois. Anota que enderezo é alcanzable desde onde, e a próxima persoa que depure isto empezará pola resposta en lugar do túnel.

Artigos relacionados