VPN de la site la site bazat pe rute vs. bazat pe politici: ce diferă

Ambele proiecte protejează același trafic cu aceeași mașinărie IPsec și diferă prin ceea ce decide ce pachet intră în tunel. Într-o conexiune bazată pe politici, selectorii de trafic negociați fac această muncă; într-una bazată pe rute, o face o rută care indică o interfață de tunel. Confundarea celor două produce firul de suport familiar în care tunelul raportează că este stabilit, iar aplicația nu ajunge nicăieri. Distincția contează cel mai mult când adaugi o rețea, rulezi un protocol de rutare sau depanezi o cale care iese în tăcere pe ieșirea greșită.

Două moduri de a decide ce intră în tunel

O VPN bazată pe politici construiește o politică de securitate care se potrivește prefixelor sursă și destinație, apoi criptează tot ce se încadrează. Partenerul trebuie să negocieze selectori compatibili, așa că domeniul efectiv ajunge să fie intersecția a ceea ce au propus ambele părți. Nimic din afara acelei intersecții nu este protejat, orice ar spune tabela de rutare.

O VPN bazată pe rute creează o interfață care reprezintă tunelul și lasă tabela de rutare să trimită trafic în ea. Daemonul IKE instalează în continuare starea și politica pe interfață, iar acesta este detaliul pe care oamenii îl sar când decid că rutele au înlocuit criptarea. Ambele proiecte criptează cu IPsec; doar mecanismul de selecție diferă.

Citește comparația de mai jos ca un set de semnături de eșec și nu ca un tabel de punctaj, pentru că niciuna dintre coloane nu câștigă de la sine.

Bazat pe politici: selectorul este contractul

Selectorii se negociază, nu doar se configurează. Propune 10.10.0.0/16 pe o parte și 10.10.1.0/24 pe cealaltă, iar asocierea va acoperi ce a stabilit negocierea, în timp ce orice alt gazdă rămâne în afara ei.

Citește starea instalată în locul fișierului de configurare. La un partener Linux, tabelele kernelului însuși sunt adevărul de bază și arată ce a supraviețuit negocierii. O politică ce numește prefixele corecte fără o stare corespunzătoare înseamnă că asocierea nu s-a ridicat niciodată. Starea împreună cu o politică pentru prefixul greșit este problema opusă și produce tunelul care pare sănătos în timp ce o subrețea nu ajunge nicăieri.

sudo ip xfrm state
sudo ip xfrm policy
sudo swanctl --list-sas

Compară ambele ieșiri cu prefixele pe care crezi că le protejezi. Acea singură comparație rezolvă majoritatea rapoartelor despre un tunel funcțional cu un server inaccesibil. Indică și ce partener trebuie schimbat, fiindcă nepotrivirea este de obicei vizibilă doar într-o direcție.

Bazat pe rute: interfața este contractul

O interfață XFRM dă tunelului un nume și o identitate, iar traficul ajunge la ea pentru că așa spune tabela de rutare. Mai multe prefixe îndepărtate devin atunci o problemă de rutare și nu una de selector, iar un protocol de rutare le poate anunța. Acesta este câștigul real, nu criptarea.

Interfața nu elimină nevoia de politică. Daemonul instalează reguli pe interfață legate de identitatea interfeței, așa că un pachet care sosește pe interfața greșită eșuează în continuare. O adresă sursă pe care partenerul nu o va accepta eșuează și ea, chiar și cu o rută perfectă. Bazat pe rute înseamnă că ruta decide intrarea, nu că politica a dispărut.

sudo ip link add xfrm0 type xfrm dev eth0 if_id 42
sudo ip route add 10.20.0.0/16 dev xfrm0
ip -s link show xfrm0
ip route get 10.20.5.10

Urmărește contoarele interfeței după ce ruta este pusă. O rută care există în timp ce contoarele rămân la zero înseamnă că nimic nu este potrivit în tunel, ceea ce indică de obicei o stare lipsă și nu o rută lipsă.

Unde cele două proiecte chiar se despart

Adăugarea unei rețele este cel mai curat test al modelului care ți se potrivește. Un proiect bazat pe rute adaugă o rută și lărgește cel mult o dată selectorul, în timp ce un proiect bazat pe politici editează perechi de prefixe la ambii parteneri și renegociază. Două subrețele stabile fac acea modificare trivială, iar douăzeci o transformă în proiect.

Niciun model nu înlocuiește un firewall, iar comparațiile se opresc de obicei înainte de acest punct. Un selector larg sau o rută largă decid ce este criptat, nu ce este permis.

Comportamentul MTU diferă și el în practică. Encapsularea reduce încărcătura utilă, iar o interfață bazată pe rute poartă propriul MTU, așa că fixarea MSS pe ambele gateway-uri evită simptomul găurii negre în care sosesc răspunsuri mici și cele mari dispar. Tunelele bazate pe politici întâlnesc același zid din cealaltă parte, fiindcă un selector nu spune nimic despre dimensiunea pachetului. Setează fixarea intenționat, în loc să dai vina pe partener.

Migrare fără pierderea căii de întoarcere

Înregistrează perechile de prefixe existente înainte de a schimba ceva, apoi mută o cale de aplicație și urmărește-o de la un capăt la altul. Un tunel care se stabilește nu este un tunel care redirecționează, iar diferența apare în direcția răspunsului.

Când partenerii se conectează dar gazdele LAN nu, inspectează ruta de retur și adresa sursă pe care o va folosi gazda îndepărtată. O gazdă cu două interfețe poate răspunde din cea greșită, iar nicio schimbare de selector nu repară asta. Capturează trafic la ambele capete înainte de a edita algoritmi.

ip route get 10.20.5.10
sudo tcpdump -ni any host 10.20.5.10 and icmp
sudo swanctl --list-conns

Păstrează o cale de administrare care nu depinde de tunel în timp ce lucrezi. Revenirea este mai ușoară când accesul propriu al gateway-ului nu călărește pe conexiunea pe care o depanezi.