Två LAN på NetBird: vilka peers som routar och vem som får prata

En arbetsstation på västra LAN öppnar en webbläsare, skriver in adressen till en applikation på östra LAN och väntar tills tiden går ut. Varje NetBird-skärm säger att peerarna är anslutna, vilket är sant och inte poängen: att vara i ett overlaynät är inte samma sak som att ha de två lokala subnäten i ett nät. Vandringen nedan börjar på den arbetsstationen och slutar med en begäran som designen medvetet avvisar, och varje stopp är något du läser av en enhet i stället för att gissa. Förvänta dig att den saknade biten är en rutt eller en policy, inte overlaynätet.

Läs felet från arbetsstationen först

Innan du öppnar administrationskonsolen, fastställ vad arbetsstationen faktiskt skickar. Dess egen routingtabell avgör om paketet går till platsens gateway, till ett lokalt gränssnitt eller ingenstans, och det beslutet syns utan något overlayverktyg. En maskin utan rutt för det avlägsna prefixet misslyckas, hur sund peerlistan än ser ut. Overlayintervallet och platsens eget prefix är olika adressrymder, och registreringen konfigurerade bara en av dem.

Skilj sedan namnuppslagning från nåbarhet, eftersom webbläsaren rapporterar båda som samma tidsgräns. Upprepa begäran efter adress från en maskin som kör NetBird-klienten och sedan från en vanlig arbetsstation som inte gör det. Om den registrerade maskinen lyckas och den vanliga misslyckas ligger gapet i den lokala routingen; om båda misslyckas, läs vidare innan du ändrar en rutt.

Välj en routing-peer per plats

En routing-peer är en värd som representerar sitt LAN i overlaynätet, så välj en Linux-maskin med stabil nåbarhet till subnätet i stället för någons skrivbordsarbetsstation. Registrera den genom den vanliga processen och sätt den i en grupp uppkallad efter rollen, eftersom nätverksresursen och policyn båda kommer att referera till den gruppen. En representant per plats förblir läsbar; en skara frivilliga som annonserar samma prefix gör varje senare fråga till en felsökningssession. Peerns adress på det lokala segmentet betyder lika mycket som identiteten i overlaynätet, eftersom den adressen blir nästa hopp som varje vanlig enhet får veta.

Skriv ned planen innan du rör konsolen, eftersom namn och prefix är där dessa designer driver: prefix, gateway, peeradress och grupp, per plats. Väst är 10.52.0.0/24 som betjänas av 10.52.0.5 och öst är 10.63.0.0/24 som betjänas av 10.63.0.5; de två grupperna är west-routers och east-routers, och inget prefix får överlappa det andra, overlayintervallet eller en annan routad destination.

Skapa resursen, behåll maskeringen

I den utrullade instrumentpanelen skapar du en nätverksresurs per plats och kopplar platsens routing-peergrupp till den. Resursen är prefixet och gruppen är värden som svarar för det, och båda måste finnas innan något annonseras. Bekräfta att den utrullade självhostade versionen överhuvudtaget har Nätverk-arbetsflödet, eftersom ett äldre gränssnitt med ett liknande namngivet ruttobjekt är en annan funktion.

Låt maskeringen vara på. NetBirds guide för plats till plats kräver det i den här uppställningen, och att stänga av det för att hålla varje ursprunglig adress synlig är inte samma design med ett hopp mindre; det ändrar vad overlayns källkontroller och policyer ser. Konsekvensen är värd att säga rakt ut: tjänsten som tar emot registrerar routing-peeren som källa, inte den enskilda arbetsstationen. Om tjänstens tillåtelselista eller revision förväntar sig arbetsstationsadresser, ändras antingen förväntan eller så måste identiteten upprätthållas vid platsens gräns före översättningen.

Auktorisera initiativtagarna, inte prefixen

En rutt gör en adress nåbar och en policy avgör vem som får använda den; det är två separata objekt med separata ägare. Skriv policyn från arbetsbelastningen och bakåt: vilken grupp som initierar, vilken resurs den riktar sig mot och vilken TCP-tjänst den behöver. Ett nätverk som annonserar båda prefixen till varje registrerad peer har skapat nåbarhet och inte avgjort något.

Läs sedan vad annat som redan är tillåtet, eftersom en smal ny regel inte upphäver en bred gammal som står över den. När öst också måste börja anslutningar mot väst, skriv den riktningen som en egen policy; returtrafik för en session som väst öppnade är en annan fråga än att tillåta nya sessioner mot öst. Om bara vissa västra arbetsstationer ska nå östapplikationen, välj dem vid platsens gräns före översättningen och behåll applikationens egen autentisering. Routing-peeren bär LAN-trafik som hela platsen och inte som overlayidentitet per användare, så redovisning per användare måste komma från någon annanstans.

Lär varje gateway nästa hopp och testa sedan en avvisning

De vanliga enheterna ser aldrig overlaynätet, så deras egen gateway behöver en statisk rutt som pekar det avlägsna prefixet mot routing-peerns LAN-adress. Detta är steget folk hoppar över, eftersom allt synligt inne i NetBird redan fungerar medan vanliga arbetsstationer fortfarande går ut på tid. Gatewayen behåller sin standardrutt som den var; detta prefix är ett tillägg, inte en ersättning.

De två ruttbeskrivningarna hör hemma i varje plats egen gatewaykonfiguration, inte i en överstyrning på värden. Båda är vanliga statiska rutter, och ingen av dem rör standardrutten:

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 med applikationen som projektet faktiskt behöver, från en vanlig arbetsstation, och notera tre saker: nästa hopp valt på sändarsidan, policyn som matchade och källadressen som tjänsten loggade. Testa också en avvisning, eftersom en design som aldrig har avvisat något har okända kanter, och avvisningen är det enda beviset på att policyn och inte routingen gör jobbet. När öst också måste initiera, starta en ny anslutning från den sidan i stället för att anta att den andra riktningen följer. Planera också omstart, uppgradering och utbyte av routing-peeren, eftersom en värd har blivit ett platsberoende.

Privata namn behöver sin egen resolverdesign, eftersom nåbarhet inte skapar DNS-poster och en fungerande IP-väg med ett trasigt namn läses exakt som en trasig väg. Om en routing-peer körs i ett molnnät, granska också leverantörens vidarebefordrings- och brandväggsregler, eftersom registreringen inte åsidosätter dem. Behåll observationerna från testet bredvid planen, eftersom nästa person som felsöker detta vill ha policyn som matchade och den loggade källadressen, inte en beskrivning av topologin.