Două LAN-uri pe NetBird: ce parteneri rutează și cine are voie să vorbească

O stație de lucru din LAN-ul vestic deschide un browser, tastează adresa unei aplicații din LAN-ul estic și așteaptă până expiră timpul. Fiecare ecran NetBird spune că partenerii sunt conectați, ceea ce este adevărat și nu contează: a fi într-o singură rețea suprapusă nu este același lucru cu a avea cele două subrețele locale într-o singură rețea. Traseul de mai jos începe de la acea stație de lucru și se termină cu o cerere pe care proiectarea o refuză intenționat, iar fiecare oprire este ceva citit de pe un dispozitiv, nu ghicit. Așteptați-vă ca piesa lipsă să fie o rută sau o politică, nu suprapunerea.

Citiți mai întâi defecțiunea de la stația de lucru

Înainte de a deschide consola de administrare, stabiliți ce trimite de fapt stația de lucru. Tabelul ei de rutare decide dacă pachetul merge la poarta sitului, la o interfață locală sau nicăieri, iar această decizie este vizibilă fără niciun instrument de suprapunere. O mașină fără rută pentru prefixul îndepărtat va eșua, oricât de sănătoasă ar arăta lista de parteneri. Intervalul suprapunerii și prefixul propriu al sitului sunt spații de adrese diferite, iar înregistrarea a configurat doar unul dintre ele.

Apoi separați rezolvarea numelor de accesibilitate, pentru că browserul raportează ambele ca același timp expirat. Repetați cererea după adresă de pe o mașină care rulează clientul NetBird și apoi de pe o stație de lucru obișnuită care nu îl rulează. Dacă mașina înregistrată reușește și cea obișnuită eșuează, decalajul este în rutarea locală; dacă ambele eșuează, continuați să citiți înainte de a schimba o rută.

Alegeți un partener de rutare pe site

Un partener de rutare este un gazdă care reprezintă LAN-ul său în suprapunere, așa că alegeți o mașină Linux cu accesibilitate stabilă la subrețea în locul stației de lucru de birou a cuiva. Înregistrați-o prin procesul normal și puneți-o într-un grup numit după rol, pentru că resursa de rețea și politica se vor referi amândouă la acel grup. Un reprezentant pe site rămâne lizibil; o mulțime de voluntari care anunță același prefix transformă fiecare întrebare ulterioară într-o sesiune de depanare. Adresa partenerului în segmentul local contează la fel de mult ca identitatea sa în suprapunere, pentru că acea adresă devine următorul salt care se spune fiecărui dispozitiv obișnuit.

Scrieți planul înainte de a atinge consola, pentru că numele și prefixele sunt locul unde aceste proiecte deraiază: prefix, poartă, adresa partenerului și grup, pe site. Vestul este 10.52.0.0/24 servit de 10.52.0.5, iar estul este 10.63.0.0/24 servit de 10.63.0.5; cele două grupuri sunt west-routers și east-routers, iar niciun prefix nu poate suprapune celălalt, intervalul suprapunerii sau o altă destinație rutată.

Creați resursa, păstrați mascarea

În panoul implementat, creați o resursă de rețea pe site și atașați-i grupul de parteneri de rutare al sitului respectiv. Resursa este prefixul, iar grupul este gazda care răspunde pentru el, și amândouă trebuie să existe înainte de a se anunța ceva. Confirmați că versiunea auto-găzduită implementată are fluxul de lucru Rețele, pentru că o interfață mai veche cu un obiect de rută cu nume similar este altă funcție.

Lăsați mascarea activă. Ghidul NetBird pentru sit-la-sit îl cere în această configurație, iar dezactivarea lui pentru a menține vizibilă fiecare adresă originală nu este aceeași proiectare cu un salt mai puțin; schimbă ce văd verificările de sursă și politicile suprapunerii. Consecința merită spusă direct: serviciul care primește înregistrează partenerul de rutare ca sursă, nu stația de lucru individuală. Dacă lista de permisiuni sau auditul acelui serviciu așteaptă adrese de stații de lucru, fie așteptarea se schimbă, fie identitatea trebuie impusă la granița sitului înainte de traducere.

Autorizați inițiatorii, nu prefixele

O rută face o adresă accesibilă, iar o politică decide cine o poate folosi; sunt două obiecte separate cu proprietari separați. Scrieți politica de la volumul de lucru înapoi: ce grup inițiază, ce resursă vizează și ce serviciu TCP îi trebuie. O rețea care anunță ambele prefixe fiecărui partener înregistrat a creat accesibilitate și nu a rezolvat nimic.

Apoi citiți ce altceva este deja permis, pentru că o regulă nouă îngustă nu revocă una veche largă aflată deasupra. Când estul trebuie să înceapă și el conexiuni spre vest, scrieți acea direcție ca politică proprie; traficul de retur pentru o sesiune deschisă de vest este altă întrebare decât permiterea de sesiuni noi spre est. Dacă doar unele stații de lucru vestice trebuie să ajungă la aplicația estică, selectați-le la granița sitului înainte de traducere și păstrați autentificarea proprie a aplicației. Partenerul de rutare transportă traficul LAN ca situl întreg și nu ca identitate de suprapunere pe utilizator, așa că evidența pe utilizator trebuie să vină de altundeva.

Învățați fiecare poartă saltul următor, apoi testați un refuz

Dispozitivele obișnuite nu văd niciodată suprapunerea, așa că propria poartă are nevoie de o rută statică ce îndreaptă prefixul îndepărtat spre adresa LAN a partenerului de rutare. Acesta este pasul pe care oamenii îl sar, pentru că tot ce este vizibil în NetBird funcționează deja în timp ce stațiile de lucru obișnuite încă expiră. Poarta își păstrează ruta implicită așa cum era; acest prefix este o adăugare, nu o înlocuire.

Cele două descrieri de rută aparțin configurației porții fiecărui sit, nu unei suprascrieri pe gazdă. Ambele sunt rute statice obișnuite și niciuna nu atinge ruta implicită:

west gateway: 10.63.0.0/24 via 10.52.0.5
east gateway: 10.52.0.0/24 via 10.63.0.5

Testați cu aplicația de care proiectul are nevoie cu adevărat, de pe o stație de lucru obișnuită, și notați trei lucruri: următorul salt ales pe partea care trimite, politica ce s-a potrivit și adresa de sursă pe care a înregistrat-o serviciul. Testați și un refuz, pentru că o proiectare care nu a refuzat niciodată nimic are margini necunoscute, iar refuzul este singura dovadă că face treaba politica, nu rutarea. Când estul trebuie să inițieze și el, porniți o conexiune nouă din acea parte în loc să presupuneți că a doua direcție urmează. Planificați și repornirea, actualizarea și înlocuirea partenerului de rutare, pentru că o gazdă a devenit o dependență a sitului.

Numele private au nevoie de propria proiectare a resolverului, pentru că accesibilitatea nu creează înregistrări DNS, iar o cale IP funcțională cu un nume stricat se citește exact ca o cale stricată. Dacă un partener de rutare rulează într-o rețea cloud, revedeați și regulile de redirecționare și de firewall ale furnizorului, pentru că înregistrarea nu le anulează. Păstrați observațiile testului lângă plan, pentru că următoarea persoană care depanează asta va vrea politica potrivită și adresa de sursă înregistrată, nu o descriere a topologiei.