Afegiu una VPN de lloc al costat del router de l’ISP sense trencar les trucades

La majoria de llocs petits ja tenen una caixa que fa internet, DHCP i la línia de veu, i aquesta caixa no portarà el túnel del lloc. Afegir una segona passarel·la per al camí privat funciona si abans de tocar cap cable decidiu qui és amo de cada ruta. El risc real no és el túnel; és canviar en silenci l’aparell que manté els telèfons registrats. Feu les cinc comprovacions en ordre i atureu-vos on una falli.

Anoteu les funcions que ja funcionen

Registreu la passarel·la per defecte, el servidor DHCP, el resolutor i l’aparell que té la registració de veu del proveïdor. En aquest exemple el router de l’ISP és 10.50.0.1, la nova passarel·la serà 10.50.0.2 i el lloc remot és 10.60.0.0/24. Res d’aquest pla no canvia les tres primeres funcions, i aquest és precisament el punt. Després confirmeu que la segona caixa pot tancar realment el túnel: mireu el protocol, el cabal esperat i si rep actualitzacions de firmware o de paquets. Un aparell amb logotip de VPN i sense camí d’actualització és una càrrega, no una addició.

Si no podeu dir qui és amo del servei de veu, atureu-vos. Canviar el router que té una registració sense pla de reversió converteix un projecte de VPN en una caiguda telefònica.

Doneu a la nova passarel·la una adreça i una feina

Reserveu la seva adreça LAN fora del pool DHCP perquè no es mogui després d’un reinici, i no li doneu cap ruta per defecte pròpia tret que vulgueu que es converteixi en camí d’internet. La seva feina és mantenir el túnel i respondre pels prefixos remots. Als amfitrions LAN que han d’arribar al lloc remot, demostreu quin camí fan ara i quin voleu després del canvi; les mateixes dues ordres abans i després són la prova més barata.

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

Si la consulta retorna el router de l’ISP i el traceroute mor a la vora d’internet, l’amfitrió encara no té camí remot, cosa que és esperable. Si retorna una cosa inesperada, resoleu-ho primer, perquè cada pas posterior assumeix aquesta base.

Trieu qui és amo de la ruta del prefix remot

L’opció A és el router de l’ISP: manté una ruta estàtica per a 10.60.0.0/24 cap a la passarel·la i cada amfitrió segueix la seva passarel·la per defecte com abans. L’opció B és per amfitrió: només les màquines que necessiten el lloc remot reben una ruta explícita per 10.50.0.2, i tota la resta queda intacta. A és més neta per a molts amfitrions, però normalment exigeix que el router del proveïdor accepti una ruta estàtica, cosa que alguns no fan. B no necessita cooperació del proveïdor, però us deixa mantenir la configuració dels amfitrions, així que encaixa amb un conjunt petit de màquines aprovades.

En tots dos casos la direcció de retorn ha d’existir. Si una resposta remota arriba a la passarel·la i la passarel·la l’envia directament a un amfitrió LAN, el trànsit salta l’estat de tallafocs que el router de l’ISP mantenia al camí d’anada. Quan la passarel·la no és el router per defecte de la LAN, aquesta asimetria és una decisió de disseny, no un error que pugueu 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

Feu permanent l’entrada a través de l’amo de la configuració de l’amfitrió, no d’un script d’accés. Una ruta que només existeix després que algú iniciï sessió fallarà el primer cop que la màquina es reiniciï per un motiu no relacionat.

Prepareu un punt d’entrada accessible

La passarel·la necessita una adreça que el lloc remot pugui assolir. Darrere del router de l’ISP això vol dir un redireccionament de port o una entrada DMZ, i tots dos depenen que el proveïdor lliuri realment el trànsit. Un redireccionament local no supera el NAT de nivell d’operador del costat del proveïdor. Si el proveïdor no us dona cap punt accessible, invertiu la direcció: deixeu que els dos llocs iniciïn cap a un concentrador que controleu. És un disseny vàlid, però afegeix una tercera dependència per a l’enviament, la confiança i la disponibilitat, i el DNS dinàmic no el substitueix.

Confirmeu el redireccionament amb una captura a la passarel·la, no amb un web que escanegi ports. Els escàners diuen que el port és tancat fins que l’escoltador s’enllaça, i un redireccionament que mai lliura trànsit es veu des de fora igual que un port tancat.

Accepteu el servei privat i la línia de veu alhora

Proveu l’operació prevista des d’un amfitrió LAN, amb DNS privat i les credencials de la mateixa aplicació. Un túnel encaminat no fa que la navegació remota sembli un segment Ethernet local, així que el descobriment i la resolució de noms necessiten els seus propis arranjaments.

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

Després confirmeu que l’accés normal a internet encara funciona des del mateix amfitrió i que els telèfons segueixen registrats; aquestes dues comprovacions atrapen un canvi accidental de la ruta per defecte, la manera més habitual que aquest projecte trenqui alguna cosa que no volia tocar. Acabeu amb una nota de recuperació escrita: quin aparell té quina funció, les adreces reservades i com treure la ruta del prefix remot en un sol pas. Un camí privat que es pot retirar net val més que un que només funciona avui.