VPN în guest și VPN pe host: care rută câștigă de fapt

Doi clienți rulează simultan, fiecare convins că deține ruta implicită, iar simptomul apare ca ceva ciudat: o aplicație a guestului funcționează, alta se rezolvă în locul greșit. Un VPN în interiorul unui guest și un VPN pe host pot coexista, dar numai când calea exterioară și politica interioară sunt de acord cine transportă ce. Pornirea ambelor nu creează un lanț de la sine. Notează mai întâi legătura, apoi schimbă un singur lucru o dată.

Notează mai întâi legătura guestului

Guestul ajunge la serverul său VPN pe calea pe care i-a dat-o hipervizorul: NAT în spatele hostului, un bridge către segmentul fizic sau o rețea doar pentru host cu rutare adăugată deasupra. Fiecare legătură schimbă ce poate vedea guestul și ce poate face hostul cu traficul lui. Sub NAT pachetele guestului par să vină de la host, așa că tunelul propriu al hostului le poate transporta fără ca guestul să știe nimic despre asta. Sub un bridge guestul are propria prezență pe segment și propria poartă implicită.

Notează legătura înainte de a atinge orice configurație, împreună cu ce client ar trebui să transporte ce aplicație. Acea propoziție rezolvă majoritatea acestor cazuri, pentru că cei doi clienți sunt de obicei construiți pe ipoteze diferite. Un guest care ar trebui să folosească tunelul hostului nu trebuie să aibă și o rută implicită concurentă proprie.

Urmărește punctul final al guestului spre exterior

Un VPN al guestului are nevoie de o cale utilizabilă către propriul server înainte ca orice altceva să funcționeze. Când tunelul hostului este activ și guestul stă în spatele NAT, strângerea de mână a guestului iese prin tunelul hostului, ceea ce este fie proiectul, fie un accident pe care nimeni nu l-a documentat. Când tunelul hostului cade și guestul depindea de el, guestul pierde conectivitatea fără o singură schimbare de partea lui. Urmărirea punctului final spre exterior îți spune care dintre cele două cazuri îl ai de fapt.

O rută largă în oricare dintre cele două contexte capturează traficul pe care celălalt client îl aștepta. O rută 0.0.0.0/0 în interiorul guestului și un client de host cu tunel complet revendică amândouă totul, iar cel care se aplică ultimul câștigă. Suprapunerile dintre rețelele virtuale ale guestului, LAN-ul local și rețelele la distanță produc același efect pentru prefixe private, cu defecțiuni care seamănă cu problemele de autentificare; comportamentul de traducere a adreselor este același descris pentru rețelele de containere.

Compară o înregistrare înainte și după

Ia o linie de bază cu tunelul hostului oprit, sau în orice stare controlată pe care o permite politica ta, și notează ruta și resolverul guestului. Apoi aplică configurația combinată și compară cele două înregistrări, păstrând intacte cerințele de confidențialitate. Dacă o linie de bază directă nu este potrivită, scrie acea limitare în înregistrare în loc să sari peste comparație.

ip route get 10.20.30.41
ip rule show
resolvectl status --no-pager | head -12

Interogarea de rută numește interfața și adresa sursă care ar transporta o destinație anume, și este cea mai utilă linie din această investigație. Lista de reguli arată dacă rutarea bazată pe politică trimite unele destinații printr-un al doilea tabel. Ieșirea resolverului arată dacă DNS-ul a urmat tunelul guestului sau a rămas pe calea hostului. Rulează aceleași trei comenzi înainte și după schimbare, iar diferența numește vinovatul.

Păstrează proprietatea clară între reporniri

Restricția de acces local a unui client de host poate bloca traficul către un NAT virtual sau un bridge, iar acea restricție este confundată frecvent cu o problemă de acreditări ale guestului. Citește comportamentul documentat al clientului în loc să dezactivezi restricția ca să treacă un test. După o corecție susținută, testează din nou aplicația guestului și politica de eșec pe care o ceri. Un host care se reconectează cu succes nu dovedește nimic despre ruta sau resolverul guestului.

Decide care parte deține ruta implicită și scrie asta în manualul de operare. O repornire a guestului sau o schimbare de rețea pe host care inversează silențios proprietatea produce un raport de eroare despre un VPN care nu a fost niciodată vinovat. Aranjamentul ar trebui să supraviețuiască unei reporniri fără ca cineva să-și amintească de ce funcționa.