De ce doar route-nopull lasă serverul de fișiere inaccesibil
Ignorarea rutelor împinse este doar jumătate dintr-un tunel divizat. Alege proprietarul rutei, adaugă manual prefixul biroului și testează trei fluxuri înainte de a declara problema rezolvată.
Serverul de fișiere se deschide bine, iar apelul video din fereastra alăturată începe să se întrerupă. Nimic nu este lent și niciun MTU nu este greșit: clientul tău a preluat lista de rute pe care i-a dat-o serverul, așa că fiecare pachet iese acum prin firewall-ul biroului. Remedierea nu este încă un steag de reglaj, ci o decizie despre cine deține tabela de rute a clientului. Acea decizie aparține unui singur loc, iar modurile de eșec de mai jos îți spun ce loc ai ales de fapt.
Decide cine deține tabela de rute
Sunt posibili trei proprietari. Serverul poate împinge rute și o poartă implicită, iar atunci clientul instalează ce i se spune și devine un tunel complet. Profilul clientului poate prelua proprietatea aruncând împingerile și purtând propriile linii de rută. Un manager de conexiuni de desktop poate deține și el decizia prin propriile proprietăți de rută și rută implicită.
Fiecare alegere eșuează altfel, de aceea merită citită tabela înainte de a edita un profil. Rândul care se potrivește simptomului tău este proprietarul pe care îl ai de fapt.
| Owner | Where it lives | Result |
|---|---|---|
| Server | server config, redirect-gateway, pushed routes | client becomes a full tunnel |
| Profile | route-nopull and its own route lines | tunnel up, office prefix missing |
| Manager | never-default plus its own routes | desktop decides, profile ignored |
Alege unul și notează-l. Amestecarea a două lasă un host a cărui cale implicită contrazice propria documentație, iar următorul inginer nu poate spune care strat a câștigat. Șterge explicit învinsul.
route-nopull filtrează împingerile, nu adaugă rute
route-nopull aparține profilului clientului, iar ordinea lui în acel fișier este irelevantă pentru că aruncă doar valorile care vin de la server. Aruncă rutele împinse, inclusiv o rută implicită împinsă, în timp ce tunelul urcă în continuare normal.
Consecința pe care oamenii o ratează este că opțiunile DHCP împinse pleacă împreună cu ele. Setările DNS trimise de server sunt și ele aruncate, așa că numele interne nu mai sunt rezolvate, deși tunelul este sănătos și serverul este accesibil după adresă.
Asta lasă un tunel fără cale către prefixul biroului dacă nu adaugi tu unul: route-nopull urmat de route 10.30.0.0 255.255.0.0 în același profil. Acea linie poartă o adresă și o mască; nu numește un următor salt.
O formă alternativă adaugă un token de poartă, route 10.30.0.0 255.255.0.0 vpn_gateway, care indică intrarea spre tunel după nume. Importatorii diferă în privința traducerii acelei variante, așa că inspectează conexiunea salvată dacă intrarea lipsește din tabela nucleului.
Verifică prin căutări de rută, nu cu ping
Un ping îți spune că ceva a răspuns. O căutare de rută îți spune ce interfață ar alege nucleul, și aceasta este întrebarea pe care ai pus-o de fapt. Patru comenzi scurte separă o rută lipsă de o rută care indică dispozitivul greșit.
Citește ce a instalat tunelul cu ip route show dev tun0. Nicio ieșire deloc înseamnă zero rute, ceea ce nu este un tunel divizat funcțional, și este rezultatul obișnuit al adăugării filtrului fără linia explicită.
Apoi verifică o adresă a biroului cu ip route get 10.30.5.7, și o adresă obișnuită de internet cu ip route get 1.1.1.1. A doua ar trebui să numească interfața fizică; dacă numește tunelul, împingerea nu a fost filtrată deloc.
În final citește ip rule, pentru că o regulă de politică lăsată de o încercare anterioară poate suprascrie tabela pe care tocmai ai corectat-o. Un profil corect cu o regulă învechită deasupra arată exact ca un profil stricat. Șterge regula adăugată ultima dată înainte de a adăuga alta.
Subrețelele suprapuse arată ca un tunel stricat
Două intervale private pot fi identice din punctul de vedere al clientului, și acolo un tunel divizat este învinuit pentru ceva ce nu a cauzat. Dacă biroul oferă același prefix pe care îl folosește routerul tău de acasă, ruta tunelului acoperă routerul și rețeaua casei pare să dispară.
Compară adresa de pe propria interfață cu ruta pe care o instalează profilul, folosind o listă simplă de adrese înainte de a schimba ceva. Suprapunerea este reală, și nicio opțiune a profilului nu o rezolvă. Ce poți repara este denumirea, ca următoarea persoană să vadă două intervale în loc de unul.
Remediile oneste sunt renumerotarea unei părți sau traducerea adreselor la birou. Fixarea unei singure rute de host pe router funcționează până când se schimbă adresa routerului, iar atunci devine un al doilea mister peste primul.
Fă decizia să supraviețuiască unei reconectări
Intrările tastate manual nu supraviețuiesc unei reconectări, iar un manager de conexiuni reconstruiește tabela la fiecare pornire a profilului. Pune decizia acolo unde se creează conexiunea, fie că este profilul, fie setările salvate ale managerului. Apoi repornește conexiunea o dată intenționat, în loc să descoperi comportamentul în timpul unui apel. Un profil care funcționează doar până la următoarea reconectare nu este terminat.
Exersează trei căi deodată: un host al biroului după adresa literală, același host după nume, și un site public obișnuit. Cel din mijloc depinde de serviciul de nume pe care l-ai configurat după ce ai renunțat la opțiunile DNS împinse, și acela eșuează în liniște.