Engada unha VPN de sitio xunto ao router do ISP sen cortar as chamadas

A maioría dos sitios pequenos xa teñen unha caixa que fai internet, DHCP e a liña de voz, e esa caixa non vai levar o túnel do sitio. Engadir unha segunda pasarela para a ruta privada funciona se antes de tocar un cable decides quen é dono de cada ruta. O risco real non é o túnel; é cambiar en silencio o dispositivo que mantén os teléfonos rexistrados. Faga as cinco comprobacións en orde e detéñase onde unha falla.

Anote as funcións que xa funcionan

Rexistre a pasarela predeterminada, o servidor DHCP, o resolvedor e o dispositivo que ten o rexistro de voz do provedor. Neste exemplo o router do ISP é 10.50.0.1, a nova pasarela será 10.50.0.2 e o sitio remoto é 10.60.0.0/24. Nada dese plan cambia as tres primeiras funcións, e ese é xustamente o punto. Despois confirme que a segunda caixa pode rematar de verdade o túnel: mire o protocolo, o rendemento esperado e se recibe actualizacións de firmware ou de paquetes. Un dispositivo con logotipo de VPN e sen ruta de actualización é unha carga, non un engadido.

Se non pode dicir quen é dono do servizo de voz, detéñase. Cambiar o router que ten un rexistro sen un plan de reversión converte un proxecto de VPN nunha caída telefónica.

Dea á nova pasarela un enderezo e unha tarefa

Reserve o seu enderezo LAN fóra do pool DHCP para que non se mova tras un reinicio, e non lle dea unha ruta predeterminada propia salvo que queira que sexa unha ruta de internet. A súa tarefa é manter o túnel e responder polos prefixos remotos. Nos equipos da LAN que deben chegar ao sitio remoto, demostre que ruta usan agora e cal quere despois do cambio; os mesmos dous comandos antes e despois son a proba máis barata.

ip route get 10.60.0.55
ip neigh show 10.50.0.2
traceroute -n 10.60.0.55

Se a consulta devolve o router do ISP e o traceroute morre no bordo de internet, o equipo aínda non ten ruta remota, o cal é esperable. Se devolve algo inesperado, resólvao primeiro, porque cada paso posterior dá por sentada esta base.

Escolla quen é dono da ruta do prefixo remoto

A opción A é o router do ISP: mantén unha ruta estática para 10.60.0.0/24 cara á pasarela e cada equipo segue a súa pasarela predeterminada como antes. A opción B é por equipo: só as máquinas que necesitan o sitio remoto reciben unha ruta explícita por 10.50.0.2, e todo o demais queda intacto. A é máis limpa para moitos equipos, pero adoita esixir que o router do provedor acepte unha ruta estática, algo que algúns non fan. B non necesita cooperación do provedor, pero déixalle o mantemento da configuración dos equipos, así que encaixa cun conxunto pequeno de máquinas aprobadas.

En ambos os casos debe existir a dirección de volta. Se unha resposta remota chega á pasarela e esta a envía directamente a un equipo da LAN, o tráfico salta o estado de cortafuegos que o router do ISP mantiña no camiño de ida. Cando a pasarela non é o router predeterminado da LAN, esa asimetría é unha decisión de deseño, non un fallo que se poida ignorar.

ip route add 10.60.0.0/24 via 10.50.0.2 dev eth0
ip route get 10.60.0.55 from 10.50.0.77

Faga permanente a entrada a través do dono da configuración do equipo, non dun script de inicio de sesión. Unha ruta que só existe despois de que alguén inicie sesión fallará a primeira vez que a máquina se reinicie por un motivo alleo.

Prepare un punto de entrada accesible

A pasarela necesita un enderezo ao que o sitio remoto poida chegar. Detrás do router do ISP iso significa unha redirección de portos ou unha entrada DMZ, e ambas dependen de que o provedor entregue de verdade o tráfico. Unha redirección local non supera o NAT de nivel de operador do lado do provedor. Se o provedor non dá un punto accesible, invirta a dirección: deixe que ambos os sitios inicien cara a un concentrador que vostede controle. É un deseño válido, pero engade unha terceira dependencia para o envío, a confianza e a dispoñibilidade, e o DNS dinámico non a substitúe.

Confirme a redirección cunha captura na pasarela, non cun sitio web que escanee portos. Os escáneres informan do porto pechado ata que o escoitador se enlaza, e unha redirección que nunca entrega tráfico vese desde fóra igual que un porto pechado.

Acepte o servizo privado e a liña de voz xuntos

Probe o funcionamento previsto desde un equipo da LAN, con DNS privado e as credenciais da propia aplicación. Un túnel encamiñado non fai que a navegación remota pareza un segmento Ethernet local, así que o descubrimento e a resolución de nomes necesitan os seus propios axustes.

curl -sS -o /dev/null -w '%{http_code}\n' https://files.example.net
ping -c 3 10.60.0.55

Logo confirme que o acceso normal a internet segue funcionando desde o mesmo equipo e que os teléfonos seguen rexistrados; esas dúas comprobacións atrapan un cambio accidental da ruta predeterminada, a forma máis habitual de que este proxecto rompa algo que nunca quixo tocar. Remate cunha nota de recuperación escrita: que dispositivo ten que función, os enderezos reservados e como quitar a ruta do prefixo remoto nun só paso. Unha ruta privada que se pode retirar limpiamente vale máis que unha que só funciona hoxe.