To LAN på NetBird: hvilke peers ruter, og hvem får snakke

En arbeidsstasjon på vest-LAN-et åpner en nettleser, skriver inn adressen til en applikasjon på øst-LAN-et og venter til det timer ut. Hver NetBird-skjerm sier at peerne er tilkoblet, noe som er sant og ikke poenget: å være i ett overleggsnettverk er ikke det samme som å ha de to lokale subnettene i ett nettverk. Gjennomgangen nedenfor starter på den arbeidsstasjonen og ender med en forespørsel designet avviser med vilje, og hvert stopp er noe du leser av en enhet i stedet for å gjette. Forvent at den manglende biten er en rute eller en policy, ikke overlegget.

Les feilen fra arbeidsstasjonen først

Før du åpner administrasjonskonsollen, fastslå hva arbeidsstasjonen faktisk sender. Dens egen rutetabell avgjør om pakken går til nettstedets gateway, til et lokalt grensesnitt eller ingen steder, og den beslutningen er synlig uten noe overleggsverktøy. En maskin uten rute for det fjerne prefikset vil feile, uansett hvor sunn peer-listen ser ut. Overleggsområdet og nettstedets eget prefiks er forskjellige adresserom, og registreringen konfigurerte bare ett av dem.

Deretter skiller du navneoppslag fra rekkevidde, fordi nettleseren rapporterer begge som samme tidsavbrudd. Gjenta forespørselen etter adresse fra en maskin som kjører NetBird-klienten, og deretter fra en vanlig arbeidsstasjon som ikke gjør det. Hvis den registrerte maskinen lykkes og den vanlige feiler, ligger gapet i lokal ruting; hvis begge feiler, les videre før du endrer en rute.

Velg én rutingspeer per nettsted

En rutingspeer er en vert som representerer sitt LAN i overlegget, så velg en Linux-maskin med stabil rekkevidde til subnettet i stedet for noens skrivebordsarbeidsstasjon. Registrer den gjennom den vanlige prosessen og sett den i en gruppe oppkalt etter rollen, fordi nettverksressursen og policyen begge vil referere til den gruppen. Én representant per nettsted forblir lesbar; en flokk frivillige som annonserer samme prefiks gjør hvert senere spørsmål til en feilsøkingsøkt. Peerens adresse på det lokale segmentet betyr like mye som identiteten i overlegget, fordi den adressen blir neste hopp som hver vanlig enhet får beskjed om.

Skriv ned planen før du rører konsollen, fordi navn og prefikser er der disse designene driver: prefiks, gateway, peer-adresse og gruppe, per nettsted. Vest er 10.52.0.0/24 betjent av 10.52.0.5, og øst er 10.63.0.0/24 betjent av 10.63.0.5; de to gruppene er west-routers og east-routers, og ingen prefiks kan overlappe den andre, overleggsområdet eller en annen rutet destinasjon.

Opprett ressursen, behold maskeringen på

I dashbordet som er satt opp, opprett én nettverksressurs per nettsted og knytt rutingspeergruppen for det nettstedet til den. Ressursen er prefikset og gruppen er verten som svarer for det, og begge må finnes før noe annonseres. Bekreft at den selvhostede versjonen som er satt opp i det hele tatt har Nettverk-arbeidsflyten, fordi et eldre grensesnitt med et lignende navngitt ruteobjekt er en annen funksjon.

La maskeringen være på. NetBirds veiledning for nettsted-til-nettsted krever det i dette oppsettet, og å slå det av for å holde hver opprinnelige adresse synlig er ikke samme design med ett hopp mindre; det endrer hva overleggets kildekontroller og policyer ser. Konsekvensen er verdt å si rett ut: tjenesten som mottar registrerer rutingspeeren som kilde, ikke den enkelte arbeidsstasjonen. Hvis tjenestens tillatelsesliste eller revisjon forventer arbeidsstasjonsadresser, endres enten forventningen, eller identiteten må håndheves ved nettstedets grense før oversettelse.

Autoriser initiativtakerne, ikke prefiksene

En rute gjør en adresse nåbar og en policy avgjør hvem som får bruke den; de er to separate objekter med separate eiere. Skriv policyen fra arbeidsbelastningen og bakover: hvilken gruppe initierer, hvilken ressurs den retter seg mot og hvilken TCP-tjeneste den trenger. Et nettverk som annonserer begge prefiksene til hver registrert peer har skapt rekkevidde og ikke avgjort noe.

Les deretter hva annet som allerede er tillatt, fordi en smal ny regel ikke opphever en bred gammel som står over den. Når øst også skal begynne tilkoblinger til vest, skriv den retningen som sin egen policy; returtrafikk for en økt vest åpnet er et annet spørsmål enn å tillate nye økter mot øst. Hvis bare noen vestlige arbeidsstasjoner skal nå østapplikasjonen, velg dem ved nettstedets grense før oversettelse og behold applikasjonens egen autentisering. Rutingspeeren bærer LAN-trafikk som hele nettstedet og ikke som overleggsidentitet per bruker, så regnskap per bruker må komme fra et annet sted.

Lær hver gateway neste hopp, og test deretter en avvisning

De vanlige enhetene ser aldri overlegget, så deres egen gateway trenger en statisk rute som peker det fjerne prefikset mot rutingspeerens LAN-adresse. Dette er trinnet folk hopper over, fordi alt synlig inne i NetBird allerede virker mens vanlige arbeidsstasjoner fortsatt timer ut. Gatewayen beholder standardruten som den var; dette prefikset er et tillegg, ikke en erstatning.

De to rutebeskrivelsene hører hjemme i hvert nettsteds egen gateway-konfigurasjon, ikke i en overstyring på verten. Begge er vanlige statiske ruter, og ingen av 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 applikasjonen prosjektet faktisk trenger, fra en vanlig arbeidsstasjon, og noter tre ting: neste hopp valgt på sendersiden, policyen som traff og kildeadressen tjenesten logget. Test også en avvisning, fordi et design som aldri har avvist noe har ukjente kanter, og avvisningen er det eneste beviset på at policyen og ikke rutingen gjør jobben. Når øst også skal initiere, start en ny tilkobling fra den siden i stedet for å anta at den andre retningen følger. Planlegg også omstart, oppgradering og utskifting av rutingspeeren, fordi én vert er blitt en nettstedavhengighet.

Private navn trenger sitt eget resolver-design, fordi rekkevidde ikke lager DNS-poster og en fungerende IP-sti med et ødelagt navn leses nøyaktig som en ødelagt sti. Hvis en rutingspeer kjører i et skynettverk, gå også gjennom leverandørens videresendings- og brannmurregler, fordi registreringen ikke overstyrer dem. Oppbevar observasjonene fra testen ved siden av planen, fordi den neste som feilsøker dette vil ha policyen som traff og den loggede kildeadressen, ikke en beskrivelse av topologien.