Rularea a doi clienți VPN simultan este o dezbatere de rutare, nu o setare de confidențialitate. Tunelul care deține ruta mai specifică primește traficul, iar celălalt rămâne conectat, dar inactiv. Gateway-ul corporativ vede atunci o conexiune care sosește din ieșirea personală, în timp ce clientul corporativ de pe mașina dvs. vede în continuare fiecare adaptor. Deciderea care dintre aceste două fapte contează este întregul exercițiu.

Tabelul de rutare alege un singur câștigător

Capturați tabelul înainte și după pornirea clientului corporativ și citiți coloana de interfață, nu doar destinația. O rută implicită simplă din tunelul exterior este ușor de înlocuit, deoarece o pereche /1 este mai specifică decât /0. Perechea literală 0.0.0.0/1 și 128.0.0.0/1 acoperă întregul spațiu IPv4 în două jumătăți și învinge orice rută implicită unică. Odată instalată, tunelul exterior apare în continuare conectat și nu transportă nimic.

ip route show default
ip route show | grep -E '^(0.0.0.0/1|128.0.0.0/1)'

Rutarea bazată pe politici poate suprascrie complet tabelul principal, așa că citiți atât regulile, cât și rutele. O regulă care trimite traficul marcat către un alt tabel câștigă înainte de a fi consultat tabelul principal. Astfel o aplicație poate rămâne pe legătura fizică în timp ce tot restul folosește tunelul.

ip rule show

Windows decide prin metrici

În Windows câștigător este ruta cu cea mai mică metrică pentru destinație, iar doi clienți pot instala amândoi o rută implicită cu metrici diferite. Citiți tabelul și configurația interfeței împreună, deoarece adaptorul cu metrica mai mică nu este întotdeauna cel la care vă așteptați. Un client care setează și o metrică de interfață poate muta ruta implicită fără a adăuga vreo rută. Adaptorul care pierde rămâne activ și pur și simplu nu primește nimic.

route print -4
Get-NetIPConfiguration | Select-Object InterfaceAlias, IPv4DefaultGateway

Comparați cele două ieșiri și numiți interfața care deține 0.0.0.0/0. Dacă ambii clienți o revendică, decide metrica, motiv pentru care un test al ordinii conexiunii poate părea inconsistent între mașini. Dacă niciuna dintre ieșiri nu arată un gateway implicit, clientul nu rulează în tunel complet și argumentul lanțului este irelevant.

Doi observatori, două vederi diferite

Gateway-ul îndepărtat vede o conexiune care sosește din ieșirea exterioară plus tot ce clientul transmite în tunelul său. Clientul local vede adaptoare, rute și existența altui tunel, deoarece rulează cu privilegii pentru a le crea. Separarea acestor vederi este punctul; a afirma că clientul nu poate observa nu este.

Presupuneți că clientul poate enumera orice dorește și proiectați pentru vederea gateway-ului. Un design care depinde de faptul că clientul rămâne orb este la o actualizare de a se rupe.

DNS și IPv6 sunt locurile unde lanțul se scurge

DNS urmează setarea de resolver care câștigă, iar aceasta nu este neapărat calea pe care o iau pachetele. Un resolver corporativ atins prin tunelul corporativ este consecvent cu designul; un resolver local atins în afara lui nu este, și expune nume pe care tunelul trebuia să le ascundă. IPv6 este a doua scurgere: un host cu stivă dublă continuă să folosească IPv6 către destinații pe care tunelul le transportă doar prin IPv4. Verificați familiile separat, deoarece un tunel doar IPv4 nu spune nimic despre rutele sau resolverele IPv6.

ip -6 route show default
resolvectl status | grep -A2 'DNS Servers'

Corectați resolverul și ruta IPv6 în mod deliberat, în loc să stivuiți un al doilea tunel deasupra. Encapsularea dublă costă și MTU, așa că o MTU internă mai mică este primul lucru de încercat când paginile se blochează după ridicarea lanțului. Un resolver care răspunde rapid nu este dovadă că este cel corect.

Articole similare