To LAN på NetBird: kva peers ruter, og kven får snakke

Ein arbeidsstasjon på vest-LAN-et opnar ein nettlesar, skriv inn adressa til ein applikasjon på aust-LAN-et og ventar til det går ut på tid. Kvar NetBird-skjerm seier at peerane er tilkopla, noko som er sant og ikkje poenget: å vere i eitt overleggsnettverk er ikkje det same som å ha dei to lokale subnettverka i eitt nettverk. Gjennomgangen nedanfor startar på den arbeidsstasjonen og endar med ein førespurnad designen avviser med vilje, og kvart stopp er noko du les av ei eining i staden for å gjette. Vent at den manglande biten er ei rute eller ein policy, ikkje overlegget.

Les feilen frå arbeidsstasjonen fyrst

Før du opnar administrasjonskonsollen, fastslå kva arbeidsstasjonen faktisk sender. Den eiga rutetabellen avgjer om pakken går til gatewayen til nettstaden, til eit lokalt grensesnitt eller ingen stad, og den avgjerda er synleg utan noko overleggsverktøy. Ei maskin utan rute for det fjerne prefikset vil feile, uansett kor sunn peer-lista ser ut. Overleggsområdet og nettstaden sitt eige prefiks er ulike adresserom, og registreringa konfigurerte berre eitt av dei.

Deretter skil du namneoppslag frå rekkevidd, fordi nettlesaren rapporterer begge som same tidsavbrot. Gjenta førespurnaden etter adresse frå ei maskin som køyrer NetBird-klienten, og deretter frå ein vanleg arbeidsstasjon som ikkje gjer det. Viss den registrerte maskina lukkast og den vanlege feilar, ligg gapet i lokal ruting; viss begge feilar, les vidare før du endrar ei rute.

Vel ein rutarpeer per nettstad

Ein rutarpeer er ein vert som representerer sitt LAN i overlegget, så vel ei Linux-maskin med stabil rekkevidd til subnettet i staden for nokon sin skrivebordsarbeidsstasjon. Registrer henne gjennom den vanlege prosessen og set henne i ei gruppe kalla opp etter rolla, fordi nettverksressursen og policyen begge vil vise til den gruppa. Éin representant per nettstad held seg lesbar; ein flokk frivillige som annonserer same prefiks gjer kvart seinare spørsmål til ei feilsøkingsøkt. Adressa til peeren på det lokale segmentet tyder like mykje som identiteten i overlegget, fordi den adressa blir neste hopp som kvar vanleg eining får beskjed om.

Skriv ned planen før du rører konsollen, fordi namn og prefiks er der desse designa driv: prefiks, gateway, peeradresse og gruppe, per nettstad. Vest er 10.52.0.0/24 betent av 10.52.0.5, og aust er 10.63.0.0/24 betent av 10.63.0.5; dei to gruppene er west-routers og east-routers, og ingen prefiks kan overlappe den andre, overleggsområdet eller ein annan ruta destinasjon.

Opprett ressursen, hald maskeringa på

I dashbordet som er sett opp, opprett ein nettverksressurs per nettstad og knyt rutarpeergruppa for den nettstaden til han. Ressursen er prefikset og gruppa er verten som svarer for det, og begge må finnast før noko blir annonsert. Stadfest at den sjølvhosta versjonen som er sett opp i det heile har Nettverk-arbeidsflyten, fordi eit eldre grensesnitt med eit liknande namngjeve ruteobjekt er ein annan funksjon.

Lat maskeringa vere på. NetBirds rettleing for nettstad-til-nettstad krev det i dette oppsettet, og å slå det av for å halde kvar opphavlege adresse synleg er ikkje same design med eitt hopp mindre; det endrar kva kildekontrollane og policyane til overlegget ser. Konsekvensen er verd å seie rett ut: tenesta som tek imot registrerer rutarpeeren som kjelde, ikkje den einskilde arbeidsstasjonen. Viss tillatingslista eller revisjonen til tenesta ventar arbeidsstasjonsadresser, blir anten forventninga endra, eller identiteten må handhevast ved grensa til nettstaden før omsetjinga.

Autoriser initiativtakarane, ikkje prefiksa

Ei rute gjer ei adresse nåbar og ein policy avgjer kven som får bruke henne; dei er to separate objekt med separate eigarar. Skriv policyen frå arbeidslasta og bakover: kva gruppe initierer, kva ressurs ho rettar seg mot og kva TCP-teneste ho treng. Eit nettverk som annonserer begge prefiksa til kvar registrert peer har skapt rekkevidd og ikkje avgjort noko.

Les deretter kva anna som allereie er tillate, fordi ei smal ny regel ikkje opphevar ei brei gammal som står over henne. Når aust òg skal byrje tilkoplingar til vest, skriv den retninga som sin eigen policy; returtrafikk for ei økt vest opna er eit anna spørsmål enn å tillate nye økter mot aust. Viss berre nokre vestlege arbeidsstasjonar skal nå austapplikasjonen, vel dei ved grensa til nettstaden før omsetjinga og hald applikasjonen sin eigen autentisering. Rutarpeeren ber LAN-trafikk som heile nettstaden og ikkje som overleggsidentitet per brukar, så rekneskap per brukar må kome frå ein annan stad.

Lær kvar gateway neste hopp, og test deretter ei avvising

Dei vanlege einingane ser aldri overlegget, så deira eigen gateway treng ei statisk rute som peikar det fjerne prefikset mot LAN-adressa til rutarpeeren. Dette er trinnet folk hoppar over, fordi alt synleg inne i NetBird allereie verkar medan vanlege arbeidsstasjonar framleis går ut på tid. Gatewayen held på standardruta slik ho var; dette prefikset er eit tillegg, ikkje ei erstatning.

Dei to rutebeskrivingane høyrer heime i gateway-konfigurasjonen til kvar nettstad, ikkje i ei overstyring på verten. Begge er vanlege statiske ruter, og ingen av dei rører standardruta:

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 treng, frå ein vanleg arbeidsstasjon, og noter tre ting: neste hopp valt på sendarsida, policyen som passa og kjeldeadressa tenesta logga. Test òg ei avvising, fordi eit design som aldri har avvist noko har ukjende kantar, og avvisinga er det einaste beviset på at policyen og ikkje rutinga gjer jobben. Når aust òg skal initiere, start ein ny tilkopling frå den sida i staden for å anta at den andre retninga følgjer. Planlegg òg omstart, oppgradering og utskifting av rutarpeeren, fordi ein vert er blitt ein nettstadavhengigheit.

Private namn treng sin eigen resolver-design, fordi rekkevidd ikkje lagar DNS-postar og ein fungerande IP-sti med eit øydelagt namn blir lesen nøyaktig som ein øydelagd sti. Viss ein rutarpeer køyrer i eit skynettverk, gå òg gjennom videresendings- og brannmurreglane til leverandøren, fordi registreringa ikkje overstyrer dei. Oppbevar observasjonane frå testen ved sida av planen, fordi den neste som feilsøkjer dette vil ha policyen som passa og den logga kjeldeadressa, ikkje ei skildring av topologien.