ZeroTier naar een LAN: UFW-routeregels, geen poorttoestemming

Een printer op het kantoor-LAN bereiken via een ZeroTier-lid klinkt als één regel, maar het zijn in werkelijkheid drie beslissingen op drie verschillende plaatsen. De overlay moet weten waar het LAN is, de Linux-host moet bereid zijn pakketten door te sturen, en het LAN moet weten hoe het antwoord teruggaat. Een inkomende regel die een poort op de gateway opent, raakt geen van die drie. Het is het verkeerde gereedschap op de juiste host.

Drie taken, drie eigenaren

De beheerde route hoort bij de ZeroTier-netwerkconfiguratie. Die vertelt leden dat een prefix bereikbaar is via een bepaald lidadres.

Doorsturen hoort bij de Linux-kernel en bij wie het firewallbeleid bezit. Die bepaalt of een pakket dat op de overlay aankomt, de fysieke interface weer verlaat. Een host die niet doorstuurt, gooit het pakket stilzwijgend weg nadat hij het heeft aangenomen. De afzender ziet een time-out en er verschijnt niets in het servicelog.

De terugweg hoort bij het LAN. De hosts en de router daarvan moeten weten dat de overlay-prefix bereikbaar is via het LAN-adres van je gateway, of iets moet het verkeer vertalen zodat de vraag nooit ontstaat.

Elk daarvan kan kloppen terwijl de andere falen, en daarom bewijst een test die alleen de gateway pingt niets over de dienst erachter.

Richt de beheerde route op het lid

Voeg een route toe voor de bedoelde LAN-prefix via het overlay-adres van de gateway, niet via het LAN-adres. Het overlay-adres is het adres dat andere leden kunnen bereiken; het LAN-adres heeft alleen betekenis op de kabel.

Leden moeten beheerde routes accepteren wil het ontwerp werken, en hun eigen lokale netwerken mogen de prefix die je aankondigt nog niet gebruiken. Een externe laptop die thuis op 192.168.60.0/24 zit, kan ook niet 192.168.60.0/24 via de overlay routeren.

Houd de aangekondigde prefix zo smal als de taak toestaat. Een groter aggregaat aankondigen om de voorkeur te beïnvloeden kan ook adresruimte opeisen die niet van jou is, en het resulterende conflict verschijnt op de apparaten die met beide netwerken verbonden zijn. Het kan een lid ook een pad laten verkiezen dat nergens heen leidt. Houd de route eerlijk en laat het beleid de rest doen.

Schrijf de prefix en het lidadres in dezelfde notitie als de firewallregels, want de meest voorkomende fout is een route die naar het verkeerde lid wijst.

Schakel doorvoer in de kernel in

Lees de lopende doorvoerwaarde voordat je iets verandert, en maak de instelling daarna permanent via het mechanisme dat je systeem al gebruikt, niet via een eenmalig commando dat bij een herstart verdwijnt.

Als UFW het beleid bezit, drukken de routeregels doorvoer uit voor een paar van bron, bestemming en interface. Die staan los van inkomende regels die een dienst op de gateway zelf openen:

sysctl net.ipv4.ip_forward
sudo ufw route allow in on zt3f2a1c9d out on eth0 proto tcp to 192.168.60.20 port 443
sudo ufw status verbose

De interfacenaam is het werkelijke overlay-apparaat op die host, dat je kunt lezen met ip link; het is geen vaste tekenreeks in alle installaties. Als de host standaard doorstuurt en UFW niet in het pad zit, wordt de routeregel genegeerd en zijn de kernelinstellingen wat telt.

Kies hoe antwoorden terugkomen

Met bronbehoud ziet de LAN-dienst het echte overlay-adres en antwoordt daarop. Dat vereist een route op de LAN-host of op zijn router die de overlay-prefix naar je gateway wijst, en dat is een wijziging buiten de Linux-doos.

Als die route niet kan worden toegevoegd, laat beperkte bronvertaling het verzoek lijken alsof het van de gateway op het LAN komt. Antwoorden komen dan lokaal terug en er is geen wijziging in LAN-routing nodig, tegen de prijs dat de oorspronkelijke bron in de servicelogs verdwijnt.

Beperk de vertaling tot de overlay-bron en de specifieke LAN-bestemming. Alles vertalen wat de LAN-interface verlaat is de brede versie die later iedereen verrast die de regels leest, en het verbergt ook verkeer dat geblokkeerd had moeten worden.

Geen van beide keuzes geeft ongevraagde toegang van het LAN terug naar willekeurige overlay-leden. Als dat gewenst is, is het een aparte regel met een eigen beoordeling.

Test vanaf een echt lid

Verbind vanaf een ander lid, niet vanaf de gateway, en vraag één toegestane dienst aan. Probeer daarna een dienst die dicht moet blijven, en herhaal beide tests na een herverbinding en na een herstart van de gateway.

Een lid dat ONLINE meldt, of een geslaagde ping naar het overlay-adres van de gateway, valideert de route, de doorvoerregel of de terugweg niet:

zerotier-cli listnetworks
ip -4 route get 192.168.60.20
sudo ufw status numbered

Het tweede commando laat zien welke interface het pakket voor de LAN-host zou gebruiken, en het derde of de routeregel bestaat in de vorm die je bedoelde. Als beide er goed uitzien en de dienst loopt nog steeds vast, is de terugweg de resterende verdachte.