Twee LAN's op NetBird: welke peers routeren en wie mag praten

Een werkstation op het westelijke LAN opent een browser, typt het adres van een applicatie op het oostelijke LAN en wacht tot het time-out gaat. Elk NetBird-scherm zegt dat de peers verbonden zijn, wat waar is en niet ter zake doet: in één overlaynetwerk zitten is niet hetzelfde als de twee lokale subnetten in één netwerk hebben. De wandeling hieronder begint bij dat werkstation en eindigt met een verzoek dat het ontwerp bewust weigert, en elke stop is iets dat je van een apparaat afleest in plaats van gokt. Verwacht dat het ontbrekende stuk een route of een beleid is, niet de overlay.

Lees de storing eerst vanaf het werkstation

Voordat je de beheerconsole opent, stel vast wat het werkstation werkelijk verstuurt. Zijn eigen routingtabel bepaalt of het pakket naar de gateway van de locatie, naar een lokale interface of nergens gaat, en die beslissing is zichtbaar zonder enig overlaygereedschap. Een machine zonder route voor het verre prefix faalt hoe gezond de peerlijst er ook uitziet. Het overlaybereik en het eigen prefix van de locatie zijn verschillende adresruimtes, en de inschrijving configureerde er maar één van.

Scheid daarna naamresolutie van bereikbaarheid, want een browser meldt beide als dezelfde time-out. Herhaal het verzoek op adres vanaf een machine met de NetBird-client en daarna vanaf een gewoon werkstation zonder. Als de ingeschreven machine slaagt en de gewone faalt, zit de kloof in lokale routering; als beide falen, lees verder voordat je een route wijzigt.

Kies één routing-peer per locatie

Een routing-peer is een host die zijn LAN in de overlay vertegenwoordigt, dus kies een Linux-machine met stabiele bereikbaarheid naar het subnet in plaats van iemands bureaubladwerkstation. Schrijf hem in via het normale proces en zet hem in een groep die naar de rol is genoemd, want de netwerkresource en het beleid verwijzen beide naar die groep. Eén vertegenwoordiger per locatie blijft leesbaar; een menigte vrijwilligers die hetzelfde prefix aankondigen maakt elke latere vraag tot een debug-sessie. Het adres van de peer op het lokale segment is net zo belangrijk als zijn identiteit in de overlay, want dat adres wordt de volgende hop die elk gewoon apparaat te horen krijgt.

Schrijf het plan op voordat je de console aanraakt, want namen en prefixen zijn waar deze ontwerpen afdrijven: prefix, gateway, peeradres en groep, per locatie. West is 10.52.0.0/24 bediend door 10.52.0.5 en oost is 10.63.0.0/24 bediend door 10.63.0.5; de twee groepen zijn west-routers en east-routers, en geen prefix mag het andere, het overlaybereik of een andere gerouteerde bestemming overlappen.

Maak de resource aan, houd masquerading aan

Maak in het uitgerolde dashboard één netwerkresource per locatie en koppel de routing-peergroep van die locatie eraan. De resource is het prefix en de groep is de host die ervoor antwoordt, en beide moeten bestaan voordat er iets wordt aangekondigd. Controleer of de uitgerolde zelfgehoste versie helemaal de Netwerken-workflow heeft, want een oudere interface met een vergelijkbaar genoemd routeobject is een andere functie.

Laat masquerading aan staan. De NetBird-gids voor locatie naar locatie vereist het in deze opstelling, en het uitschakelen om elk oorspronkelijk adres zichtbaar te houden is niet hetzelfde ontwerp met één hop minder; het verandert wat de broncontroles en het beleid van de overlay zien. De consequentie is het waard ronduit te zeggen: de ontvangende dienst registreert de routing-peer als bron, niet het individuele werkstation. Als de toelatingslijst of audit van die dienst werkstationadressen verwacht, verandert ofwel de verwachting ofwel moet de identiteit bij de grens van de locatie worden afgedwongen vóór de vertaling.

Machtig de initiatiefnemers, niet de prefixen

Een route maakt een adres bereikbaar en een beleid bepaalt wie het mag gebruiken; dat zijn twee aparte objecten met aparte eigenaren. Schrijf het beleid van de werkbelasting terug: welke groep initieert, welke resource het richt en welke TCP-dienst het nodig heeft. Een netwerk dat beide prefixen aan elke ingeschreven peer aankondigt, heeft bereikbaarheid geschapen en niets beslist.

Lees daarna wat er al is toegestaan, want een smalle nieuwe regel trekt een brede oude die erboven staat niet in. Wanneer oost ook verbindingen naar west moet beginnen, schrijf die richting als eigen beleid; retourverkeer voor een sessie die west opende is een andere vraag dan nieuwe sessies naar oost toestaan. Als alleen sommige westelijke werkstations de oostelijke applicatie mogen bereiken, selecteer ze dan bij de grens van de locatie vóór de vertaling en houd de eigen authenticatie van de applicatie in stand. De routing-peer draagt LAN-verkeer als de hele locatie en niet als overlayidentiteit per gebruiker, dus administratie per gebruiker moet ergens anders vandaan komen.

Leer elke gateway de volgende hop en test dan een weigering

De gewone apparaten zien de overlay nooit, dus hun eigen gateway heeft een statische route nodig die het verre prefix naar het LAN-adres van de routing-peer wijst. Dat is de stap die mensen overslaan, omdat alles wat zichtbaar is binnen NetBird al werkt terwijl gewone werkstations nog steeds time-out gaan. De gateway houdt zijn standaardroute zoals die was; dit prefix is een toevoeging, geen vervanging.

De twee routebeschrijvingen horen in de gatewayconfiguratie van elke locatie, niet in een overschrijving op de host. Beide zijn gewone statische routes, en geen ervan raakt de standaardroute:

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 met de applicatie die het project echt nodig heeft, vanaf een gewoon werkstation, en noteer drie dingen: de volgende hop die aan de zendende kant is gekozen, het beleid dat overeenkwam en het bronadres dat de dienst logde. Test ook een weigering, want een ontwerp dat nooit iets heeft geweigerd heeft onbekende randen, en de weigering is het enige bewijs dat het beleid en niet de routering het werk doet. Wanneer oost ook moet initiëren, start dan een nieuwe verbinding vanaf die kant in plaats van aan te nemen dat de tweede richting volgt. Plan ook het herstarten, upgraden en vervangen van de routing-peer, want één host is een afhankelijkheid van de locatie geworden.

Privénamen hebben hun eigen resolverontwerp nodig, want bereikbaarheid maakt geen DNS-records en een werkend IP-pad met een gebroken naam leest precies als een gebroken pad. Als een routing-peer in een cloudnetwerk draait, bekijk dan ook de doorstuur- en firewallregels van de provider, want de inschrijving heft ze niet op. Bewaar de observaties van de test naast het plan, want de volgende persoon die dit debugt wil het overeenkomende beleid en het gelogde bronadres, niet een beschrijving van de topologie.