Els usuaris remots no arriben al segon lloc a través del concentrador VPN

Un usuari remot es connecta al concentrador, arriba al servidor de fitxers de la mateixa LAN del concentrador i tot sembla saludable. Després obre un recurs compartit a 10.20.0.50 a la seu central, on arriba el concentrador per un túnel independent entre seus, i expira. Els dos túnels estan aixecats i els dos comptadors pugen, així que cap túnel està trencat. Travessar el concentrador són tres decisions d’encaminament en tres dispositius, i un túnel només transporta els prefixos per als quals es va construir. Aquest és l’ordre que comprovo i la comanda que mostra si cada pas és cert.

El trànsit necessita tres consultes, no un sol túnel

Cada dispositiu fa la seva pròpia coincidència de prefix més llarg i la oblida. El portàtil ha d’enviar 10.20.0.50 cap al túnel i no cap al seu encaminador local. El concentrador ha de prendre un paquet que ha arribat per la interfície d’accés remot i lliurar-lo a la interfície entre seus. La seu central ha d’enviar una resposta per a l’adreça de l’usuari de tornada pel túnel. Que falli qualsevol de les tres coses es veu igual al navegador: silenci.

Per això provar cada túnel per separat demostra tan poc. Fer ping a l’adreça LAN del concentrador exercita la primera decisió, i fer ping al concentrador des de la seu central exercita la tercera. El paquet que falla té el conjunt d’usuaris com a origen i el segon lloc com a destinació, així que apunteu aquests prefixos primer. Aquí el conjunt és 10.80.0.0/24, la LAN del concentrador és 10.10.0.0/24 i la seu central és 10.20.0.0/24.

Empenyeu el prefix remot cap al client remot

En un OpenVPN servidor d’accés remot, el client aprèn les rutes en connectar-se. Sense un push, un client amb túnel dividit envia 10.20.0.50 al seu propi portal i el paquet no entra mai al túnel.

push "route 10.20.0.0 255.255.255.0"

Una ruta empenyuda s’aplica quan el client es connecta, així que un usuari que es queda en línia no veu res fins que es torna a connectar. Verifiqueu-ho al client: ip route get 10.20.0.50 a Linux, route print a Windows. La sortida ha de nomenar la interfície del túnel.

El push no ajuda el concentrador. És un missatge al client, no una ruta al servidor ni un permís per reenviar, així que un concentrador amb la línia push perfecta encara descarta el flux un salt més enllà. Aquesta és la raó habitual per la qual la gent conclou que el push ha fallat.

Doneu al concentrador una ruta de sortida real

El concentrador necessita el seu propi següent salt per al prefix de la seu central. En un túnel encaminat és una ruta ordinària per la interfície entre seus, i una sola ordre mostra tant la ruta triada com l’origen triat:

ip route get 10.20.0.50 from 10.80.0.25
sudo ip route add 10.20.0.0/24 via 172.30.0.2 dev s2s0

Quan el tram entre seus és ell mateix OpenVPN, la ruta pot viure en aquella configuració amb l’adreça de túnel del parell com a portal: route 10.20.0.0 255.255.255.0 172.30.0.2. El portal no és opcional. Deixeu-lo fora i el següent salt cau en un valor per defecte de la implementació, que difereix entre un client d’un sol parell i un concentrador amb diversos parells.

L’IPsec basat en polítiques és diferent: el nucli del concentrador envia el paquet al seu portal LAN habitual i la política l’atrapa a la sortida, així que una ruta de túnel o no fa res o desvia el trànsit més enllà de la política. Mireu l’origen a l’ordre anterior, perquè 10.10.0.1 en lloc de l’adreça del conjunt vol dir que el nucli ha triat una adreça que el costat remot rebutjarà. iroute tampoc no és la resposta; diu al servidor quin client posseeix una subxarxa darrere del seu propi túnel, no on enviar el trànsit per a un tercer lloc.

Esteneu el costat remot cap al conjunt d’usuaris

La seu central ja cobreix la LAN del concentrador, 10.10.0.0/24. El conjunt d’usuaris és un segon prefix i també ha de ser als selectors, o cap política no cobreix una resposta adreçada a 10.80.0.25. Cada parell nomena el mateix parell de conjunts de prefixos des del seu costat:

# strongSwan swanctl.conf, on the hub
local_ts  = 10.10.0.0/24, 10.80.0.0/24
remote_ts = 10.20.0.0/24

# on the headquarters peer
local_ts  = 10.20.0.0/24
remote_ts = 10.10.0.0/24, 10.80.0.0/24

El local_ts d’un dispositiu és el remote_ts de l’altre. Copieu el bloc del concentrador a la seu central i el parell queda invertit, així que la child SA no s’aixeca mai.

La sintaxi més antiga de ipsec.conf fa servir un leftsubnet separat per comes. L’associació de seguretat en curs conserva els selectors que ha negociat, així que torneu a establir el túnel després de l’edició. Un selector canviat a les 10:00 i provat contra una SA aixecada a les 09:40 encara falla, mentre que el fitxer de configuració sembla correcte tot el temps.

Després comproveu l’últim salt. ip route get 10.80.0.25 a l’extrem remot ha d’apuntar cap al túnel. Si el servei fa servir un encaminador LAN com a portal per defecte, aquell encaminador també necessita la ruta de tornada, o la resposta mor allà. Executar tcpdump -ni eth1 host 10.80.0.25 en aquest segment mostra si la resposta ha sortit de l’extrem.

Permeteu el flux al concentrador

El reenviament ha d’estar activat i el camí permès. Acoteu les regles als dos prefixos en lloc d’acceptar-ho tot entre les interfícies.

sysctl -w net.ipv4.ip_forward=1
iptables -I FORWARD -i tun0 -o s2s0 -s 10.80.0.0/24 -d 10.20.0.0/24 -j ACCEPT
iptables -I FORWARD -i s2s0 -o tun0 -s 10.20.0.0/24 -d 10.80.0.0/24 -j ACCEPT

El filtratge de camí invers és la fallada silenciosa del costat: amb les dues potes en interfícies diferents, rp_filter=1 pot descartar la resposta mentre el comptador de la regla d’acceptació no es mou mai. Compareu iptables -vnL FORWARD abans i després d’un intent. Una regla que no s’incrementa mai no s’assoleix, així que mireu una capa més avall en lloc de reescriure-la.

Si només un grup necessita trànsit, poseu la ruta en un fitxer per client sota client-config-dir en lloc d’ampliar el push global. El NAT d’origen al concentrador també elimina la necessitat d’una ruta de tornada al costat remot, però amaga l’adreça de l’usuari, així que els registres del lloc remot i les regles basades en adreces deixen de distingir els usuaris.

Verifiqueu des del client i després revertiu en ordre invers

Proveu un port TCP, no només ICMP, perquè un ping pot passar mentre el servei segueix bloquejat. nc -vz 10.20.0.50 445 i traceroute -n 10.20.0.50 des del client mostren si el segon salt és l’adreça de túnel del concentrador. Al concentrador, tcpdump -ni tun0 host 10.20.0.50 i el mateix filtre a la interfície entre seus: una petició a totes dues sense resposta a cap de les dues trasllada el problema al costat remot.

Després proveu una cosa que ha de quedar bloquejada. Si també respon un equip que el conjunt no hauria d’assolir mai, heu obert més que el trànsit i hauríeu d’estrenyir les regles. Un concentrador que reenvia tot a cada branca passa la primera prova i falla la segona.

Manteniu una llista de reversió, perquè han canviat quatre objectes i tres són fàcils d’oblidar: la ruta empenyuda, la ruta del concentrador, els selectors i les regles de tallafoc. Desfeu-los en ordre invers, torneu a establir la SA i feu que un usuari es reconnecti. Una reversió parcial deixa una ruta que apunta a un túnel que ja no coincideix, cosa més difícil de llegir que el silenci original. El manual d’OpenVPN 2.6 documenta push, route i iroute per a la vostra versió.