ZeroTier till ett LAN: UFW-rutregler, inte ett porttillstånd

Att nå en skrivare på kontorets LAN via en ZeroTier-medlem låter som en enda regel, men det är i själva verket tre beslut på tre olika ställen. Overlayn måste veta var LANet finns, Linux-värden måste vara villig att vidarebefordra paket, och LANet måste veta hur svaret skickas tillbaka. En inkommande regel som öppnar en port på gatewayen rör ingen av dessa. Det är fel verktyg på rätt värd.

Tre jobb, tre ägare

Den hanterade rutten tillhör ZeroTier-nätverkskonfigurationen. Den talar om för medlemmarna att ett prefix är nåbart via en viss medlemsadress.

Vidarebefordran tillhör Linux-kärnan och den som äger dess brandmurspolicy. Den avgör om ett paket som kommer in på overlayn lämnar det fysiska gränssnittet igen. En värd som inte vidarebefordrar slänger tyst paketet efter att ha tagit emot det. Avsändaren ser en tidsgräns och ingenting dyker upp i tjänsteloggen.

Returvägen tillhör LANet. Dess värdar och dess router måste veta att overlay-prefixet är nåbart via gatewayens LAN-adress, eller så måste något översätta trafiken så att frågan aldrig uppstår.

Var och en av dessa kan vara korrekt medan de andra misslyckas, och därför bevisar ett test som bara pingar gatewayen ingenting om tjänsten bakom den.

Rikta den hanterade rutten mot medlemmen

Lägg till en rutt för det avsedda LAN-prefixet via gatewayens overlay-adress, inte via dess LAN-adress. Overlay-adressen är den som andra medlemmar kan nå; LAN-adressen har bara betydelse på kabeln.

Medlemmarna måste acceptera hanterade rutter för att designen ska fungera, och deras egna lokala nätverk får inte redan använda prefixet du annonserar. En fjärrbärbar dator som hemma ligger på 192.168.60.0/24 kan inte heller routa 192.168.60.0/24 via overlayn.

Håll det annonserade prefixet så smalt som uppgiften tillåter. Att annonsera ett större aggregat för att påverka preferensen kan också göra anspråk på adressutrymme du inte äger, och konflikten som uppstår syns på enheterna som är anslutna till båda näten. Det kan också få en medlem att föredra en väg som inte leder någonstans. Håll rutten ärlig och låt policyn göra resten.

Skriv prefixet och medlemsadressen i samma anteckning som brandmursreglerna, eftersom det vanligaste felet är en rutt som pekar på fel medlem.

Slå på vidarebefordran i kärnan

Läs det körande vidarebefordringsvärdet innan du ändrar något, och gör sedan inställningen permanent via mekanismen som ditt system redan använder, inte via ett engångskommando som försvinner vid omstart.

Om UFW äger policyn uttrycker dess ruttregler vidarebefordran för ett par av källa, destination och gränssnitt. De är åtskilda från inkommande regler som öppnar en tjänst på själva gatewayen:

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

Gränssnittsnamnet är den faktiska overlay-enheten på den värden, som du kan läsa med ip link; det är inte en fast sträng över installationer. Om värden vidarebefordrar som standard och UFW inte är i vägen ignoreras ruttregeln, och det är kärninställningarna som gäller.

Välj hur svar kommer tillbaka

Med källbevarande ser LAN-tjänsten den verkliga overlay-adressen och svarar på den. Det kräver en rutt på LAN-värden eller dess router som pekar overlay-prefixet mot din gateway, och det är en ändring utanför Linux-lådan.

När den rutten inte kan läggas till får begränsad källöversättning förfrågan att se ut som om den kom från gatewayen på LANet. Svaren kommer då tillbaka lokalt och ingen ändring av LAN-routingen behövs, till priset av att den ursprungliga källan försvinner i tjänsteloggarna.

Begränsa översättningen till overlay-källan och den specifika LAN-destinationen. Att översätta allt som lämnar LAN-gränssnittet är den breda varianten som senare överraskar den som läser reglerna, och den döljer också trafik som borde ha blockerats.

Inget av valen ger oombedd åtkomst från LANet tillbaka till godtyckliga overlay-medlemmar. Om det önskas är det en separat regel med egen granskning.

Testa från en riktig medlem

Anslut från en annan medlem, inte från gatewayen, och begär en tillåten tjänst. Prova sedan en tjänst som ska förbli stängd, och upprepa båda testerna efter en återanslutning och efter en omstart av gatewayen.

En medlem som rapporterar ONLINE, eller en lyckad ping till gatewayens overlay-adress, validerar inte rutten, vidarebefordringsregeln eller returvägen:

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

Det andra kommandot visar vilket gränssnitt paketet skulle använda till LAN-värden, och det tredje om ruttregeln finns i den form du avsåg. Om båda ser riktiga ut och tjänsten fortfarande tar slut på tid är returvägen den kvarvarande misstänkta.