Nicio rută nu repară un pool VPN care se suprapune cu LAN-ul tău

Aplicația susține că tunelul este sănătos, și totuși jumătate dintre destinațiile de care ai nevoie nu răspund niciodată. Reflexul este să adaugi o rută sau să cobori o metrică, și exact acel reflex este mitul care trebuie ucis primul. Când LAN-ul propriu al clientului și pool-ul tunelului revendică același prefix, tabela de rutare ține două fapte incompatibile, și nici o rută implicită nici o metrică nu le rezolvă. Reparația este o decizie de adresare, și nicio editare de rute nu o înlocuiește.

De ce o rută suplimentară nu poate despărți un prefix

O rută nu poate separa două revendicări pe un prefix, de aceea mișcarea înțeleaptă este să nu mai cauți linia de rută corectă. Stiva nu va pune un prefix identic în fața rutei conectate, iar o intrare mai specifică prinde adresa, dar face gazda locală care o deține inaccesibilă. Ceea ce pare o problemă de rutare este o coliziune de adresare, și ambele reparații schimbă adrese, nu rute. Testează afirmația pe propria mașină înainte de a o accepta.

ip route get 192.168.1.50
route -n get 192.168.1.50
Find-NetRoute -RemoteIPAddress 192.168.1.50

Întreabă sistemul despre o singură adresă și observă ce interfață numește. Linux, macOS și Windows răspund fiecare cu o căutare doar-citire care raportează interfața aleasă și următorul salt fără să transmită nimic. Când răspunsul indică adaptorul fizic în timp ce tunelul este activ, nucleul tratează adresa ca fiind pe legătură, nu ca ceva ce tunelul ar putea transporta.

Pune prefixul acordat de furnizor lângă cel pe care îl deservește routerul de acasă și compară-le ca șiruri. Potrivirea exactă este cazul clar, iar un pool mai larg al furnizorului care conține subrețeaua de acasă eșuează la fel, doar că e mai ușor de ratat. Două prefixe care doar arată asemănător nu sunt o coliziune, așa că notează-le pe amândouă înainte de a schimba ceva.

Citește pool-ul pe care clientul l-a primit efectiv

Citește ce a primit clientul, nu pagina de marketing a furnizorului. Crește detaliul jurnalului unui client OpenVPN și rutele împinse de server apar în el, dezvăluind prefixele tunelului; în alte locuri pool-ul apare în detaliile conexiunii sau pe adaptorul însuși. Cere furnizorului lista completă a intervalelor private pe care le folosește, pentru că un singur /24 azi poate fi două mâine. A evita blocurile RFC 1918 uzuale nu este același lucru cu a evita alocarea care ți-a fost dată efectiv.

Un pool se poate și micșora sau muta între regiuni, așa că lista are nevoie de o dată și de un responsabil. Tratează orice răspuns al furnizorului mai vechi decât ultima ta schimbare de plan ca o presupunere, nu ca un fapt. Întreabă din nou înainte de a te angaja la un interval, și păstrează răspunsul cu notițele de rețea ca următoarea persoană să moștenească dovada.

Renumerotarea este reparația pe care o poți face

Dacă serverul VPN nu este al tău ca să-l schimbi, mutarea LAN-ului de acasă este singura reparație disponibilă, și aceasta este situația obișnuită cu un furnizor comercial. Alege un interval în afara pool-ului furnizorului și în afara intervalelor de care ai putea avea nevoie mai târziu, și verifică-l față de fiecare alt site la care ajungi printr-un tunel. Așteaptă-te la o întrerupere scurtă și la o coadă mai lungă de dispozitive uitate: unul care mai ține adresa veche pare să funcționeze până când are nevoie de gateway.

1. Mai întâi inventarul: adresa routerului însuși, domeniul DHCP, rezervările, redirecționările de port și orice dispozitiv a cărui adresă a fost scrisă de mână.
2. Apoi schimbă prefixul LAN al routerului și domeniul DHCP împreună într-o fereastră de mentenanță, și reînnoiește lease-urile cu fir înaintea celor fără fir.
3. Apoi corectează adresele statice: imprimante, stocare în rețea, orice cu un gateway scris fix.
4. În final, reconectează clientul VPN și confirmă că adresa tunelului nu se mai ciocnește cu LAN-ul.

Parcurge adresele în această ordine și nu pe toate deodată, și ține intervalul vechi documentat o vreme, ca un dispozitiv învechit să fie recognoscibil, nu misterios. Un dispozitiv care nu reînnoiește niciodată se anunță prin faptul că nu ajunge la gateway, ceea ce este un indiciu mult mai bun decât un apel la suport. Dacă routerul dă lease-uri mai lungi de o zi, scurtează-le pe durata ferestrei.

Ce poate și ce nu poate un alias

Când serverul este al tău, traducerea adreselor pe client poate expune prefixul de la distanță într-un interval local liber, astfel încât aceeași gazdă răspunde la o a doua adresă. OpenVPN-ul comunitar face asta cu client-nat, iar acea directivă este specifică acelui client, absentă în clienții comerciali și mobili cu care oamenii o compară de obicei. Aranjamentul cere o rută care să corespundă traducerii, un interval liber pentru alias și un server dispus să răspundă la adresa netradusă a clientului. Nimic din toate acestea nu ajută când clientul aparține unui furnizor administrat pe care nu îl poți configura.

După ce schimbarea intră în vigoare, ajunge la o gazdă locală și la una de la distanță mai întâi după adresă și apoi după nume, notând ruta pe care sistemul o alege de fiecare dată. Un nume se poate încă rezolva în intervalul vechi, așa că adresele și numele merită verificări independente. Repornește un client și un dispozitiv din partea serverului dacă vreunul a rămas pornit în timpul schimbării, pentru că intrările de vecinătate din cache trăiesc mai mult decât editarea.

Scrie prefixele la care ai ajuns acolo unde oamenii chiar se uită: notițele de rețea, câmpul de comentariu al routerului, pagina de întâmpinare. Cineva va alege din nou 192.168.1.0/24, și coliziunea se întoarce cu el.