To LAN'er på NetBird: hvilke peers ruter, og hvem må tale

En arbejdsstation på det vestlige LAN åbner en browser, skriver adressen på en applikation på det østlige LAN og venter, indtil den timer ud. Hver NetBird-skærm siger, at peerne er forbundet, hvilket er sandt og uden betydning: at være i ét overlay-netværk er ikke det samme som at have de to lokale undernet i ét netværk. Gennemgangen nedenfor starter ved den arbejdsstation og slutter med en anmodning, som designet afviser med vilje, og hvert stop er noget, du kan læse ud af en enhed i stedet for at gætte. Forvent, at det manglende stykke er en rute eller en politik, ikke overlayout.

Læs fejlen fra arbejdsstationen først

Før du åbner administrationskonsollen, skal du fastslå, hvad arbejdsstationen faktisk sender. Dens egen rutetabel afgør, om pakken går til stedets gateway, til en lokal grænseflade eller ingen steder, og den beslutning er synlig uden noget overlay-værktøj. En maskine uden rute til det fjerne præfiks vil fejle, uanset hvor sund peer-listen ser ud. Overlay-intervallet og stedets eget præfiks er forskellige adresserum, og tilmeldingen konfigurerede kun ét af dem.

Skil derefter navneopløsning fra rækkevidde, fordi browseren rapporterer begge som samme timeout. Gentag anmodningen via adresse fra en maskine, der kører NetBird-klienten, og derefter fra en almindelig arbejdsstation, der ikke gør. Hvis den tilmeldte maskine lykkes og den almindelige fejler, ligger hullet i den lokale routing; hvis begge fejler, så læs videre, før du ændrer en rute.

Vælg én routing-peer per sted

En routing-peer er en vært, der repræsenterer sit LAN på overlayout, så vælg en Linux-maskine med stabil rækkevidde til undernettet i stedet for nogens skrivebordsarbejdsstation. Tilmeld den via den normale proces, og sæt den i en gruppe opkaldt efter rollen, fordi netværksressourcen og politikken begge vil henvise til den gruppe. Én repræsentant per sted forbliver læsbar; en flok frivillige, der annoncerer samme præfiks, gør hvert senere spørgsmål til en fejlretningssession. Peerens adresse på det lokale segment betyder lige så meget som dens identitet på overlayout, fordi den adresse bliver det næste hop, som hver almindelig enhed får at vide.

Skriv planen ned, før du rører konsollen, fordi navne og præfikser er der, hvor disse designs driver: præfiks, gateway, peer-adresse og gruppe, per sted. Vest er 10.52.0.0/24 betjent af 10.52.0.5, og øst er 10.63.0.0/24 betjent af 10.63.0.5; de to grupper er west-routers og east-routers, og ingen af præfikserne må overlappe det andet, overlay-intervallet eller en anden routed destination.

Opret ressourcen, behold maskering slået til

I det udrullede dashboard opretter du én netværksressource per sted og knytter det steds routing-peer-gruppe til den. Ressourcen er præfikset, og gruppen er den vært, der svarer for det, og begge skal findes, før noget annonceres. Bekræft, at den udrullede selvhostede version overhovedet har arbejdsgangen Netværk, fordi en ældre grænseflade med et lignende navngivet ruteobjekt er en anden funktion.

Lad maskeringen være slået til. NetBirds guide til site-to-site kræver det i denne opsætning, og at slå det fra for at holde hver oprindelig adresse synlig er ikke det samme design med ét hop færre; det ændrer, hvad overlayets kildekontroller og politikker ser. Konsekvensen er værd at sige rent ud: den modtagende tjeneste registrerer routing-peeren som kilde, ikke den enkelte arbejdsstation. Hvis den tjenestes tilladelsesliste eller revision forventer arbejdsstationers adresser, ændres forventningen, eller også skal identiteten håndhæves ved stedets grænse før oversættelse.

Autoriser initiativtagerne, ikke præfikserne

En rute gør en adresse tilgængelig, og en politik afgør, hvem der må bruge den; de er to separate objekter med separate ejere. Skriv politikken fra arbejdsbyrden og bagud: hvilken gruppe initierer, hvilken ressource den retter sig mod, og hvilken TCP-tjeneste den har brug for. Et netværk, der annoncerer begge præfikser til hver tilmeldt peer, har skabt rækkevidde og ikke afgjort noget.

Læs derefter, hvad der ellers allerede er tilladt, fordi en snæver ny regel ikke ophæver en bred gammel, der står over den. Når øst også skal begynde forbindelser til vest, skriv den retning som sin egen politik; returtrafik for en session, vest åbnede, er et andet spørgsmål end at tillade nye sessioner mod øst. Hvis kun nogle vestlige arbejdsstationer skal nå den østlige applikation, skal du vælge dem ved stedets grænse før oversættelse og beholde applikationens egen autentificering. Routing-peeren bærer LAN-trafik som hele stedet i stedet for som en overlay-identitet per bruger, så regnskab per bruger skal komme fra et andet sted.

Lær hver gateway det næste hop, og test så en afvisning

De almindelige enheder ser aldrig overlayout, så deres egen gateway har brug for en statisk rute, der peger det fjerne præfiks mod routing-peerens LAN-adresse. Det er det trin, folk springer over, fordi alt synligt inde i NetBird allerede virker, mens almindelige arbejdsstationer stadig timer ud. Gatewayen beholder sin standardrute, som den var; dette præfiks er en tilføjelse, ikke en erstatning.

De to rutebeskrivelser hører i hvert steds egen gateway-konfiguration, ikke i en tilsidesættelse på værten. Begge er almindelige statiske ruter, og ingen af dem rører standardruten:

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

Test med den applikation, projektet faktisk har brug for, fra en almindelig arbejdsstation, og noter tre ting: det næste hop, der vælges på afsendersiden, den politik, der matchede, og den kildeadresse, tjenesten loggede. Test også en afvisning, fordi et design, der aldrig har afvist noget, har ukendte kanter, og afvisningen er det eneste bevis på, at politikken og ikke routing gør arbejdet. Når øst også skal initiere, så start en ny forbindelse fra den side i stedet for at antage, at den anden retning følger. Planlæg også routing-peerens genstart, opgradering og udskiftning, fordi én vært er blevet en stedsafhængighed.

Private navne har brug for deres eget resolver-design, fordi rækkevidde ikke skaber DNS-poster, og en fungerende IP-sti med et brudt navn læses præcis som en brudt sti. Hvis en routing-peer kører inde i et skynetværk, skal du også gennemgå udbyderens videresendelses- og firewallregler, fordi tilmelding ikke tilsidesætter dem. Opbevar testens observationer ved siden af planen, fordi den næste, der fejlretter dette, vil have den matchede politik og den registrerede kildeadresse, ikke en beskrivelse af topologien.