VPN de la sit la sit sau acces la distanță: ce leagă fiecare
Unul leagă gateway-uri, celălalt leagă dispozitive. Comparați selectorii de trafic cu rutele, planificați adresarea, apoi testați redirecționarea și politica de la un host real.
Ambele soluții se numesc VPN și rezolvă probleme diferite. Un tunel de la sit la sit leagă două gateway-uri, astfel încât fiecare host din spatele lor poate ajunge la adresele permise de cealaltă parte fără să instaleze nimic. Un tunel de acces la distanță leagă dispozitive individuale la o rețea, câte un client o dată. Comparația contează pentru că majoritatea erorilor de implementare provin din configurarea unei soluții în timp ce se așteaptă comportamentul celeilalte, iar simptomul este de obicei un timeout la un serviciu pe care tunelul l-a atins într-adevăr.
Două soluții, două limite
| 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 |
Niciuna dintre soluții nu extinde un domeniu de difuzare LAN. Dispozitivele din partea îndepărtată nu apar într-o listă de descoperire locală, iar așteptarea asta este prima presupunere de abandonat. Numele DNS private pe care le publicați deliberat sunt mai previzibile decât orice protocol de descoperire și rezistă la schimbarea furnizorului.
Luați 10.10.0.0/24 într-un sit și 10.20.0.0/24 în celălalt. Gateway-ul A are nevoie de o rută sau de un selector de trafic care trimite prefixul 10.20.0.0/24 în tunel, iar gateway-ul B are nevoie de imaginea oglindită. Hosturile din ambele părți folosesc apoi conectivitate IP obișnuită și nu află niciodată că există un tunel. Această invizibilitate este caracteristica, și tot din acest motiv defecțiunile arată ca erori obișnuite de rețea, nu ca erori de tunel.
Bazat pe politică și bazat pe rută nu sunt același tunel
Într-o implementare IPsec bazată pe politică, selectorii de trafic negociat definesc exact ce perechi sursă-destinație sunt protejate. Dacă apare o subrețea nouă în spatele unui gateway și niciun selector nu o acoperă, tunelul rămâne activ, iar noua subrețea pur și simplu nu este transportată. Într-o soluție bazată pe rută, o interfață primește traficul și decide tabela de rutare, ceea ce face ca adăugarea unui prefix să fie o modificare de rutare, nu o renegociere a tunelului.
StrongSwan expune ambele perspective direct, iar citirea lor împreună este modalitatea de a afla ce model ați implementat de fapt.
swanctl --list-sas
ip xfrm policy
ip -4 route show table all | grep -E '10\.(10|20)\.'O listă de selectori care omite prefixul de care aveți nevoie explică defecțiunea fără nicio captură de pachete, iar o rută care indică interfața greșită explică defecțiunea oglindă la întoarcere. Citiți-le pe amândouă înainte de a renegocia ceva, pentru că o reînnoire de cheie nu va adăuga un selector pe care nu l-ați configurat niciodată.
Planificați adresarea înainte de tunel
Intervalele suprapuse sunt eroarea de proiectare care nu poate fi corectată prin configurare. Dacă ambele situri folosesc 192.168.1.0/24, un host care are nevoie de 192.168.1.50 are doi candidați și nicio modalitate de a alege. Tunelul se va autentifica, asocierile de securitate se vor stabili, iar decizia de rutare va fi oricum greșită sau ambiguă.
Alegeți una dintre trei opțiuni oneste: renumerotați un sit, traduceți intervalul suprapus la gateway astfel încât fiecare parte să vadă un prefix distinct, sau renunțați la rutarea directă pentru acele hosturi și publicați serviciul altfel. Fiecare are un cost, iar prima este de obicei cea mai ieftină pe un orizont de doi ani. Decideți înainte ca tunelul să existe, pentru că ulterior schimbarea atinge fiecare dispozitiv cu adresa veche.
Rezolvați și problema MTU devreme. Un tunel reduce încărcătura utilă, iar o soluție care se bazează pe fragmentare se comportă diferit de una care fixează MSS la gateway-uri.
Redirecționarea și politica stau în afara tunelului
Gateway-ul trebuie să fie dispus să redirecționeze pachete între interfața tunelului și interfața LAN, iar ambele direcții au nevoie de politică ce permite serviciul. În Linux acestea sunt două setări separate, plus regulile de firewall care decid dacă fluxul redirecționat este permis.
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 ACCEPTHostul receptor adaugă un al treilea strat: propriul firewall trebuie să accepte în continuare un client din subrețeaua îndepărtată. Un server de fișiere care permite doar /24-ul său local va respinge traficul redirecționat de la 10.20.0.7, oricât de sănătos ar părea tunelul, iar această respingere se citește ușor ca o defecțiune de rutare.
Testați de la un host, nu de la gateway
Un ping trimis de gateway-ul însuși poate urma o altă adresă sursă și o altă politică decât traficul de utilizator redirecționat. Asta îl face un test slab și uneori înșelător: reușește în timp ce aplicația eșuează, sau eșuează în timp ce aplicația funcționează.
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/nullFolosiți un host real, o adresă sursă reală și protocolul real pe care îl folosește aplicația. Apoi citiți separat calea de întoarcere, pentru că o direcție de dus care funcționează fără rută de întoarcere produce un timeout identic cu cel al unui serviciu blocat.
Alegeți soluția după întrebarea la care răspundeți: uniți rețele sau admiteți dispozitive? Tot restul, inclusiv ce furnizor configurați, decurge din acel răspuns.