D’emplaçament a emplaçament o accés remot per VPN: què uneix cadascun
Un uneix passarel·les, l’altre uneix dispositius. Compareu els selectors de trànsit amb les rutes, planifiqueu l’adreçament i després proveu el reenviament i la política des d’un amfitrió real.
Tots dos dissenys s’anomenen VPN i resolen problemes diferents. Un túnel d’emplaçament a emplaçament uneix dues passarel·les, de manera que cada amfitrió que hi ha al darrere pot arribar a les adreces permeses de l’altre costat sense instal·lar res. Un túnel d’accés remot uneix dispositius individuals a una xarxa, un client alhora. La comparació és important perquè la majoria d’errors de desplegament provenen de configurar un disseny tot esperant el comportament de l’altre, i el símptoma sol ser un temps d’espera esgotat en un servei al qual el túnel sí que ha arribat.
Dos dissenys, dues fronteres
| Site-to-site | Remote access | |
|---|---|---|
| Endpoints | two gateways | a gateway and each client |
| Who configures | network owners | each user or an MDM |
| Scope of reach | whatever the gateways route | whatever the client is granted |
| Broadcast discovery | not carried | not carried |
Cap dels dos dissenys estén un domini de difusió LAN. Els dispositius de l’altre costat no apareixen en cap llista de descoberta local, i esperar que ho facin és el primer supòsit que cal abandonar. Els noms DNS privats que publiqueu deliberadament són més predictibles que qualsevol protocol de descoberta i sobreviuen a un canvi de proveïdor.
Agafeu 10.10.0.0/24 en un emplaçament i 10.20.0.0/24 a l’altre. La passarel·la A necessita una ruta o un selector de trànsit que enviï el prefix 10.20.0.0/24 al túnel, i la passarel·la B necessita la imatge mirall. Els amfitrions d’ambdós costats fan servir llavors connectivitat IP ordinària i no arriben a saber mai que existeix un túnel. Aquesta invisibilitat és la característica, i també és la raó per la qual les fallades semblen errors de xarxa corrents en lloc d’errors de túnel.
Basat en política i basat en ruta no són el mateix túnel
En un desplegament d’IPsec basat en política, els selectors de trànsit negociats defineixen exactament quins parells d’origen i destinació estan protegits. Si apareix una subxarxa nova darrere d’una passarel·la i cap selector la cobreix, el túnel continua actiu i la subxarxa nova simplement no es transporta. En un disseny basat en ruta, una interfície rep el trànsit i la taula d’encaminament decideix, cosa que fa que afegir un prefix sigui un canvi d’encaminament i no una renegociació del túnel.
StrongSwan exposa tots dos punts de vista directament, i llegir-los junts és com s’esbrina quin model heu desplegat realment.
swanctl --list-sas
ip xfrm policy
ip -4 route show table all | grep -E '10\.(10|20)\.'Una llista de selectors que omet el prefix que us interessa explica la fallada sense cap captura de paquets, i una ruta que apunta a la interfície equivocada explica la fallada mirall de tornada. Llegiu les dues coses abans de renegociar res, perquè una renovació de clau no afegirà cap selector que no hàgiu configurat mai.
Planifiqueu l’adreçament abans del túnel
Els rangs solapats són l’error de disseny que no es pot arreglar amb configuració. Si tots dos emplaçaments fan servir 192.168.1.0/24, un amfitrió que necessita 192.168.1.50 té dos candidats i cap manera de triar. El túnel s’autenticarà, les associacions de seguretat s’establiran i la decisió d’encaminament serà igualment errònia o ambigua.
Trieu una de tres opcions honestes: renumerar un emplaçament, traduir el rang solapat a la passarel·la perquè cada costat vegi un prefix diferent, o renunciar a l’encaminament directe per a aquests amfitrions i publicar el servei d’una altra manera. Cadascuna té un cost, i la primera sol ser la més barata en un horitzó de dos anys. Decidiu-ho abans que el túnel existeixi, perquè després el canvi afecta tots els dispositius que tinguin l’adreça antiga.
Resoleu també la qüestió de l’MTU d’hora. Un túnel redueix la càrrega útil, i un disseny que depèn de la fragmentació es comporta de manera diferent d’un que fixa l’MSS a les passarel·les.
El reenviament i la política queden fora del túnel
La passarel·la ha d’estar disposada a reenviar paquets entre la interfície del túnel i la interfície LAN, i totes dues direccions necessiten una política que permeti el servei. A Linux són dos paràmetres separats, a més de les regles del tallafocs que decideixen si el flux reenviat s’admet o no.
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 ACCEPTL’amfitrió receptor afegeix una tercera capa: el seu propi tallafocs encara ha d’acceptar un client de la subxarxa remota. Un servidor de fitxers que només permet la seva /24 local rebutjarà el trànsit reenviat des de 10.20.0.7, per molt saludable que sembli el túnel, i aquest rebuig es llegeix fàcilment com una fallada d’encaminament.
Proveu-ho des d’un amfitrió, no des de la passarel·la
Un ping originat per la mateixa passarel·la pot seguir una adreça d’origen i una política diferents de les del trànsit d’usuari reenviat. Això el converteix en una prova feble i, de vegades, enganyosa: té èxit mentre l’aplicació falla, o falla mentre l’aplicació 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/nullFeu servir un amfitrió real, una adreça d’origen real i el protocol real que utilitza l’aplicació. Després llegiu el camí de tornada per separat, perquè una direcció d’anada que funciona sense ruta de retorn produeix un temps d’espera esgotat idèntic al d’un servei bloquejat.
Trieu el disseny segons la pregunta que responeu: esteu unint xarxes o admetent dispositius? Tota la resta, inclòs quin proveïdor configureu, se’n deriva.