ZeroTier til et LAN: UFW-ruteregler, ikke en porttillatelse

Å nå en skriver på kontorets LAN gjennom et ZeroTier-medlem høres ut som én regel, men det er faktisk tre beslutninger på tre forskjellige steder. Overlayet må vite hvor LAN-et er, Linux-verten må være villig til å videresende pakker, og LAN-et må vite hvordan svaret sendes tilbake. En inngående regel som åpner en port på gatewayen berører ingen av disse. Det er feil verktøy brukt på riktig vert.

Tre jobber, tre eiere

Den administrerte ruten tilhører ZeroTier-nettverkskonfigurasjonen. Den forteller medlemmene at et prefiks er tilgjengelig gjennom en bestemt medlemsadresse.

Videresending tilhører Linux-kjernen og den som eier brannmurpolicyen. Den avgjør om en pakke som kommer inn på overlayet, forlater den fysiske grensesnittet igjen. En vert som ikke videresender, vil stille forkaste pakken etter å ha godtatt den. Avsenderen ser en tidsavbrudd, og ingenting dukker opp i tjenesteloggen.

Returveien tilhører LAN-et. Vertene og ruteren der må vite at overlay-prefikset er tilgjengelig gjennom LAN-adressen til gatewayen din, eller så må noe oversette trafikken slik at spørsmålet aldri oppstår.

Hver av disse kan være riktig mens de andre svikter, og derfor beviser en test som bare pinger gatewayen ingenting om tjenesten bak den.

Rett den administrerte ruten mot medlemmet

Legg til en rute for det tiltenkte LAN-prefikset gjennom overlay-adressen til gatewayen, ikke gjennom LAN-adressen. Overlay-adressen er den andre medlemmer kan nå; LAN-adressen gir bare mening på kabelen.

Medlemmene må godta administrerte ruter for at designet skal virke, og deres egne lokale nettverk må ikke allerede bruke prefikset du annonserer. En ekstern bærbar PC som hjemme ligger på 192.168.60.0/24 kan heller ikke rute 192.168.60.0/24 gjennom overlayet.

Hold det annonserte prefikset så smalt som oppgaven tillater. Å annonsere et større aggregat for å påvirke preferansen kan også gjøre krav på adresseplass du ikke eier, og konflikten som oppstår vises på enhetene som er koblet til begge nettverkene. Det kan også få et medlem til å foretrekke en vei som ikke fører noe sted. Hold ruten ærlig og la policyen gjøre resten.

Skriv prefikset og medlemsadressen i samme notat som brannmurreglene, for det vanligste problemet er en rute som peker på feil medlem.

Slå på videresending i kjernen

Les den kjørende videresendingsverdien før du endrer noe, og gjør deretter innstillingen varig gjennom mekanismen systemet ditt allerede bruker, ikke gjennom en engangskommando som forsvinner ved omstart.

Hvis UFW eier policyen, uttrykker rutereglene videresending for et par av kilde, destinasjon og grensesnitt. De er atskilt fra inngående regler som åpner en tjeneste på selve 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

Grensesnittnavnet er den faktiske overlay-enheten på den verten, som du kan lese med ip link; det er ikke en fast streng på tvers av installasjoner. Hvis verten videresender som standard og UFW ikke er i veien, blir ruteregelen ignorert, og det er kjerneinnstillingene som betyr noe.

Velg hvordan svar kommer tilbake

Med kildebevaring ser LAN-tjenesten den virkelige overlay-adressen og svarer på den. Det krever en rute på LAN-verten eller ruteren dens som peker overlay-prefikset mot gatewayen din, og det er en endring utenfor Linux-boksen.

Når den ruten ikke kan legges til, får begrenset kildeoversettelse forespørselen til å se ut som den kom fra gatewayen på LAN-et. Svarene kommer da tilbake lokalt, og det trengs ingen endring i LAN-rutingen, men prisen er at den opprinnelige kilden forsvinner fra tjenesteloggene.

Begrens oversettelsen til overlay-kilden og den spesifikke LAN-destinasjonen. Å oversette alt som forlater LAN-grensesnittet er den brede versjonen som senere overrasker enhver som leser reglene, og den skjuler også trafikk som burde vært blokkert.

Ingen av valgene gir uoppfordret tilgang fra LAN-et tilbake til vilkårlige overlay-medlemmer. Hvis det er ønsket, er det en egen regel med sin egen gjennomgang.

Test fra et ekte medlem

Koble til fra et annet medlem, ikke fra gatewayen, og be om én tillatt tjeneste. Prøv deretter en tjeneste som skal holde seg lukket, og gjenta begge testene etter en gjentilkobling og etter en omstart av gatewayen.

Et medlem som rapporterer ONLINE, eller en vellykket ping til overlay-adressen til gatewayen, validerer ikke ruten, videresendingsregelen eller returveien:

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

Den andre kommandoen viser hvilket grensesnitt pakken ville brukt til LAN-verten, og den tredje viser om ruteregelen finnes i den formen du mente. Hvis begge ser riktige ut og tjenesten fortsatt timer ut, er returveien den gjenstående mistenkte.