Utilizatorii la distanță nu ajung la al doilea sit prin hub-ul VPN

Un utilizator la distanță se conectează la hub, ajunge la serverul de fișiere din LAN-ul propriu al hub-ului și totul pare sănătos. Apoi deschide o partajare pe 10.20.0.50 la sediul central, la care hub-ul ajunge printr-un tunel separat sit-la-sit, iar cererea expiră. Ambele tuneluri sunt active și ambii contori cresc, deci niciun tunel nu este defect. Trecerea prin hub înseamnă trei decizii de rutare pe trei dispozitive, și un tunel transportă doar prefixele pentru care a fost construit. Iată ordinea în care verific și comanda care arată dacă fiecare pas este adevărat.

Tranzitul cere trei căutări, nu un singur tunel

Fiecare dispozitiv face propria potrivire de prefix cel mai lung și o uită. Laptopul trebuie să trimită 10.20.0.50 în tunel, nu către routerul local. Hub-ul trebuie să ia un pachet care a sosit pe interfața de acces la distanță și să îl predea interfeței sit-la-sit. Sediul central trebuie să trimită un răspuns pentru adresa utilizatorului înapoi prin tunel. Oricare dintre cele trei eșecuri arată la fel în browser: tăcere.

De aceea testarea fiecărui tunel separat dovedește atât de puțin. Ping pe adresa LAN a hub-ului exersează prima decizie, iar ping pe hub din sediul central exersează a treia. Pachetul care eșuează are ca sursă pool-ul de utilizatori și ca destinație al doilea sit, așa că notați mai întâi acele prefixe. Aici pool-ul este 10.80.0.0/24, LAN-ul hub-ului este 10.10.0.0/24, iar sediul central este 10.20.0.0/24.

Împingeți prefixul îndepărtat la clientul la distanță

Pe un server de acces la distanță OpenVPN clientul învață rutele la conectare. Fără push, un client cu tunel divizat trimite 10.20.0.50 la propriul gateway și pachetul nu intră niciodată în tunel.

push "route 10.20.0.0 255.255.255.0"

O rută împinsă intră în vigoare când clientul se conectează, așa că un utilizator care rămâne online nu vede nimic până nu se reconectează. Verificați pe client: ip route get 10.20.0.50 în Linux, route print în Windows. Ieșirea ar trebui să numească interfața tunelului.

push nu ajută hub-ul. Este un mesaj către client, nu o rută pe server și nu o permisiune de redirecționare, așa că un hub cu o linie push perfectă tot pierde fluxul un hop mai departe. Acesta este motivul obișnuit pentru care oamenii concluzionează că push a eșuat.

Dați hub-ului o rută de ieșire reală

Hub-ul are nevoie de propriul următor hop pentru prefixul sediului central. Pe un tunel rutat aceasta este o rută obișnuită prin interfața sit-la-sit, iar o singură comandă arată atât ruta aleasă, cât și sursa aleasă:

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

Acolo unde segmentul sit-la-sit este el însuși OpenVPN, ruta poate locui în acea configurație cu adresa de tunel a partenerului ca gateway: route 10.20.0.0 255.255.255.0 172.30.0.2. Gateway-ul nu este opțional. Dacă îl omiteți, următorul hop cade pe o valoare implicită a implementării, care diferă între un client cu un singur punct îndepărtat și un hub cu mai mulți parteneri.

IPsec bazat pe politici este diferit: nucleul hub-ului trimite pachetul la gateway-ul LAN obișnuit, iar politica îl prinde la ieșire, așa că o rută de tunel fie nu face nimic, fie duce traficul pe lângă politică. Urmăriți sursa din comanda de mai sus, pentru că 10.10.0.1 în locul adresei pool-ului înseamnă că nucleul a ales o adresă pe care partea îndepărtată o va respinge. Nici iroute nu este răspunsul; îi spune serverului ce client deține o subrețea în spatele propriului tunel, nu unde să trimită trafic pentru un al treilea sit.

Extindeți partea îndepărtată la pool-ul de utilizatori

Sediul central acoperă deja LAN-ul hub-ului, 10.10.0.0/24. Pool-ul de utilizatori este un al doilea prefix și trebuie să fie și în selectori, altfel nicio politică nu acoperă un răspuns adresat către 10.80.0.25. Fiecare partener numește aceeași pereche de seturi de prefixe din partea lui:

# 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

local_ts al unui dispozitiv este remote_ts al celuilalt. Copiați blocul hub-ului la sediul central și perechea se inversează, așa că SA-ul copil nu urcă niciodată.

Sintaxa mai veche ipsec.conf folosește leftsubnet separat prin virgule. Asociația de securitate activă păstrează selectorii pe care i-a negociat, așa că restabiliți tunelul după editare. Un selector schimbat la 10:00 și testat împotriva unui SA care a urcat la 09:40 tot eșuează, deși fișierul de configurare pare corect tot timpul.

Apoi verificați ultimul hop. ip route get 10.80.0.25 pe capătul îndepărtat ar trebui să indice în tunel. Dacă serviciul folosește un router LAN ca gateway implicit, acel router are nevoie și de ruta de întoarcere, altfel răspunsul moare acolo. Rularea tcpdump -ni eth1 host 10.80.0.25 pe acel segment arată dacă răspunsul a plecat deloc din capăt.

Permiteți fluxul pe hub

Redirecționarea trebuie activată și calea permisă. Limitați regulile la cele două prefixe în loc să acceptați tot între interfețe.

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

Filtrarea pe calea inversă este eșecul tăcut de alături: cu cele două segmente pe interfețe diferite, rp_filter=1 poate arunca răspunsul în timp ce contorul regulii de acceptare nu se mișcă deloc. Comparați iptables -vnL FORWARD înainte și după o încercare. O regulă care nu crește niciodată nu este atinsă, așa că priviți un nivel mai jos în loc să o rescrieți.

Dacă doar un grup are nevoie de tranzit, puneți ruta într-un fișier per client sub client-config-dir în loc să lărgiți push-ul global. Source NAT pe hub elimină și nevoia unei rute de întoarcere pe partea îndepărtată, dar ascunde adresa utilizatorului, așa că jurnalele sitului îndepărtat și regulile bazate pe adrese nu mai disting utilizatorii.

Verificați din client, apoi reveniți în ordine inversă

Testați un port TCP, nu doar ICMP, pentru că un ping poate trece în timp ce serviciul rămâne blocat. nc -vz 10.20.0.50 445 și traceroute -n 10.20.0.50 din client arată dacă al doilea hop este adresa tunelului hub-ului. Pe hub, tcpdump -ni tun0 host 10.20.0.50 și același filtru pe interfața sit-la-sit: o cerere pe ambele fără răspuns pe niciuna mută problema pe partea îndepărtată.

Apoi testați ceva care trebuie să rămână blocat. Dacă un host la care pool-ul nu ar trebui să ajungă niciodată răspunde și el, ați deschis mai mult decât tranzitul și ar trebui să restrângeți regulile. Un hub care redirecționează tot către fiecare ramură trece primul test și eșuează al doilea.

Păstrați o listă de revenire, pentru că patru obiecte s-au schimbat și trei sunt ușor de uitat: ruta împinsă, ruta hub-ului, selectorii și regulile firewall-ului. Anulați-le în ordine inversă, restabiliți SA-ul și lăsați un utilizator să se reconecteze. O revenire parțială lasă o rută care indică un tunel ce nu mai corespunde, iar asta e mai greu de citit decât tăcerea inițială. Manualul OpenVPN 2.6 documentează push, route și iroute pentru versiunea dumneavoastră.