Cum trimiți prin VPN doar o singură subrețea privată

Alegeți între o rută pe client, o rută împinsă de server și selectori negociați, apoi duceți o subrețea privată fără un tunel complet.

O subrețea privată prin tunel și tot restul pe calea obișnuită este o cerere mică cu foarte multe feluri de a greși. Rezultatul nu este decis de căsuța numită split tunneling, ci de locul unde decizia este impusă: în tabela de rute a clientului însuși, într-o rută împinsă de server sau într-o politică negociată de cele două capete. Alegeți stratul greșit și obțineți fie un tunel complet pe care nu l-ați dorit niciodată, fie o rută către un tunel pe care cealaltă parte refuză să îl accepte. Folosesc un test cu trei condiții înainte de a deschide orice configurație, apoi aleg unul dintre mecanismele de mai jos.

Trei condiții care decid proiectarea

În primul rând, aveți nevoie de prefixul și masca exacte de la proprietarul rețelei. Rețeaua 10.x nu este un prefix; 10.20.0.0/16 este. Confirmați că nu se suprapune cu LAN-ul de acasă, cu un pod Docker sau cu alt VPN pe care îl rulați, pentru că o suprapunere face ruta ambiguă și nucleul alege intrarea la care nu v-ați gândit.

În al doilea rând, cine răspunde traficului de întoarcere. Rutarea unui pachet în tunel îl duce doar la serverul VPN. Dacă subrețeaua se află în spatele altui router care nu are rută înapoi către grupul de clienți, serverul trebuie să mascheze traficul, sau acel router trebuie să învețe grupul dumneavoastră. Nicio rută pe partea clientului nu repară o cale de întoarcere lipsă.

În al treilea rând, punctul de impunere. Unii clienți instalează o rută și sistemul de operare face restul. Alții negociază o politică, iar o politică pe care gateway-ul nu o acceptă nu produce niciun tunel: pachetele sunt aruncate fără o eroare evidentă. Aflați care dintre cele două este cazul dumneavoastră înainte de a scrie ceva.

WireGuard: AllowedIPs este tabela de rute

Pe client, AllowedIPs enumeră destinațiile care pot intra în tunel, iar wg-quick transformă fiecare intrare într-o rută obișnuită. Deci jumătatea client a acestei sarcini este o singură linie.

[Peer]
PublicKey = ...
Endpoint = vpn.example.net:51820
AllowedIPs = 10.20.0.0/16

Acum comparați intrarea serverului pentru același client. Ea descrie ce va trimite serverul clientului, ceea ce este de obicei adresa de tunel a clientului, nu subrețeaua privată.

[Peer]
PublicKey = ...
AllowedIPs = 10.99.0.2/32

Inversarea acestor două este greșeala pe care o văd cel mai des. Plasarea 10.20.0.0/16 sub secțiunea peer a serverului afirmă că întreaga subrețea se află în spatele acelui client, iar aceasta este o pretenție de la site la site, nu o permisiune. Pachetele care nu se potrivesc cu AllowedIPs al niciunui peer sunt aruncate în tăcere, așa că o intrare greșită arată exact ca o problemă de firewall.

Dacă administrați singur rutele, setați Table = off sub [Interface] și adăugați ruta dorită. Atunci nimic nu este adăugat automat, așa că ruta aparține de ceea ce ridică interfața.

OpenVPN: împingeți ruta, apoi asigurați-vă că ajunge

Pe un server normal schimbarea este o singură directivă în configurația serverului, lângă grupul de clienți.

push "route 10.20.0.0 255.255.0.0"

Clientul o adaugă atunci când se conectează. Modul de eșec apare când același profil împinge și redirect-gateway, sau când cineva a adăugat deja route-nopull: primul transformă sesiunea într-un tunel complet, iar al doilea aruncă fiecare rută împinsă, inclusiv a dumneavoastră.

Un client care are nevoie de un comportament îngust față de un server cu tunel complet ar trebui să ignore doar părțile de care nu are nevoie. În OpenVPN 2.4 și versiunile ulterioare, pull-filter există exact pentru asta.

pull-filter ignore "redirect-gateway"
route 10.20.0.0 255.255.0.0

Țineți familiile de adrese separate: o rută IPv4 împinsă nu face nimic pentru un serviciu intern care se rezolvă în IPv6, iar acel serviciu eșuează prin tunel în timp ce tot restul pare în regulă.

Când subrețeaua privată nu este pe serverul VPN, ci în spatele altui client, serverul trebuie informat. Adăugați un fișier pentru fiecare client prin client-config-dir care conține iroute 10.20.0.0 255.255.0.0, plus route corespunzător, ca ceilalți clienți să învețe calea. Fără iroute serverul nu are niciun motiv să trimită acel prefix exact prin acel tunel.

IPsec: selectorii de trafic trebuie să fie de acord

Cu IPsec nu există nicio rută de împins. Cele două capete negociază ce adrese trăiesc în tunel, iar traficul din afara selectorilor conveniți nu este nici criptat, nici trimis prin el. Pe un client strongSwan selectorii sunt expliciți.

leftsubnet=192.168.1.0/24
rightsubnet=10.20.0.0/16

Dacă gateway-ul este configurat cu 0.0.0.0/0 pe ambele părți, îngustarea IKEv2 reduce de obicei SA-ul copil la intersecția celor două propuneri, ceea ce este rezultatul dorit. Unele gateway-uri resping în schimb o propunere care nu se potrivește cu selectorii configurați, iar jurnalul arată atunci un SA copil eșuat, nu o plângere de rutare. Când se întâmplă asta, schimbarea aparține gateway-ului, pentru că o rută pe client nu poate crea un tunel pentru un selector pe care cealaltă parte nu îl va accepta.

Pe Windows clientul integrat ascunde aceeași decizie în spatele a două setări. Divizarea tunelului trebuie să fie activă, iar prefixul trebuie înregistrat pe profil.

Set-VpnConnection -Name Office -SplitTunneling $true
Add-VpnConnectionRoute -ConnectionName Office -DestinationPrefix 10.20.0.0/16

Înregistrarea prefixului este ceea ce îl face să supraviețuiască unei reconectări, ceea ce o rută adăugată manual nu face.

Țineți punctul final și DNS-ul în afara deciziei

Punctul final al VPN trebuie să rămână accesibil fără tunel, altfel tunelul se prăbușește în el însuși. Când este rutat doar 10.20.0.0/16, asta este automat, fiindcă punctul final este o adresă publică. Pe un profil cu tunel complet nu este, iar clientul are nevoie de o rută de gazdă explicită către punctul final înainte ca tunelul să urce.

DNS este o a doua decizie pe care împingerea unei rute nu o ia pentru dumneavoastră. Numele interne se rezolvă de obicei printr-un resolver accesibil doar din rețeaua privată. Dacă serverul împinge un server DNS, fiecare nume trece prin el; dacă nu o face, numele interne fie eșuează, fie se rezolvă public la ceva la care nu v-ați gândit. DNS-ul divizat păstrează un domeniu de căutare pe resolverul intern, dar asta depinde de suportul clientului, așa că tratați-l ca sarcină separată și nu ca efect secundar al rutării.

Verificați, apoi reporniți și verificați din nou

Trei sondaje acoperă întrebarea rutării. Întrebați nucleul unde ar merge o adresă îndepărtată, luați ceva din interiorul subrețelei, apoi confirmați că o cerere publică obișnuită iese în continuare prin conexiunea dumneavoastră normală.

ip route get 10.20.5.7
curl -sS http://10.20.5.7/health
curl -sS https://ifconfig.me

Prima linie numește o interfață. Dacă numește interfața dumneavoastră fizică, ruta nu a ajuns niciodată. Pe Windows, Find-NetRoute -RemoteIPAddress 10.20.5.7 răspunde la aceeași întrebare, iar ultimul sondaj ar trebui să arate în continuare adresa dumneavoastră obișnuită, nu cea a serverului VPN.

Apoi reporniți. Rutele adăugate manual dispar, iar rutele din profil, dintr-o configurație împinsă sau din AllowedIPs revin. Dacă accesul îngust funcționează înainte de repornire și eșuează după, vina este în modul în care pornește tunelul, nu în rută.

Înainte de a-l considera terminat, confirmați patru lucruri: prefixul a venit de la proprietarul rețelei și nu se suprapune cu nimic local, calea de întoarcere există sau o înlocuiește o regulă de mascare, mecanismul pe care l-ați configurat este cel care impune rutarea pe platforma dumneavoastră, iar aceleași sondaje trec după o repornire curată. Notele strongSwan despre forwardare merită citite dacă calea de întoarcere este partea care continuă să eșueze.

Articole similare