ZeroTier til eit LAN: UFW-rutereglar, ikkje eit portløyve

Å løyve ein port på gatewayen er ikkje det same som å videresende til ein vert bak han. Set den administrerte ruta, slå på videresending og vel ein returveg.

Å nå ein skrivar på kontor-LAN-et gjennom eit ZeroTier-medlem høyrest ut som éin regel, men det er faktisk tre avgjerder på tre ulike stader. Overlayet må vite kvar LAN-et er, Linux-verten må vere viljug til å videresende pakkar, og LAN-et må vite korleis svaret vert sendt tilbake. Ein inngåande regel som opnar ein port på gatewayen rører ingen av desse. Det er feil verktøy brukt på rett vert.

Tre jobbar, tre eigarar

Den administrerte ruta høyrer til ZeroTier-nettverkskonfigurasjonen. Ho fortel medlemmane at eit prefiks er tilgjengeleg gjennom ei bestemt medlemsadresse.

Videresending høyrer til Linux-kjernen og til den som eig brannmurpolitikken. Ho avgjer om ein pakke som kjem inn på overlayet, forlèt det fysiske grensesnittet att. Ein vert som ikkje videresender, vil stille kaste pakken etter å ha teke han imot. Avsendaren ser ein tidsavbrot, og ingenting dukkar opp i tenesteloggen.

Returvegen høyrer til LAN-et. Vertane og rutaren der må vite at overlay-prefikset er tilgjengeleg gjennom LAN-adressa til gatewayen din, eller så må noko omsetje trafikken slik at spørsmålet aldri oppstår.

Kvar av desse kan vere rett medan dei andre sviktar, og difor beviser ein test som berre pingar gatewayen ingenting om tenesta bak han.

Rett den administrerte ruta mot medlemmet

Legg til ei rute for det tiltenkte LAN-prefikset gjennom overlay-adressa til gatewayen, ikkje gjennom LAN-adressa. Overlay-adressa er den andre medlemmar kan nå; LAN-adressa gjev berre meining på kabelen.

Medlemmane må godta administrerte ruter for at designet skal verke, og deira eigne lokale nettverk må ikkje alt bruke prefikset du kunngjer. Ein ekstern berbar PC som heime ligg på 192.168.60.0/24 kan heller ikkje rute 192.168.60.0/24 gjennom overlayet.

Hald det kunngjorde prefikset så smalt som oppgåva tillèt. Å kunngjere eit større aggregat for å påverke preferansen kan også krevje adresseplass du ikkje eig, og konflikten som oppstår, viser seg på einingane som er kopla til begge nettverka. Det kan også få eit medlem til å føretrekkje ein veg som ikkje fører nokon stad. Hald ruta ærleg og lat politikken gjere resten.

Skriv prefikset og medlemsadressa i same notat som brannmurreglane, for det vanlegaste problemet er ei rute som peikar på feil medlem.

Slå på videresending i kjernen

Les den køyrande videresendingsverdien før du endrar noko, og gjer deretter innstillinga varig gjennom mekanismen systemet ditt alt brukar, ikkje gjennom ein eingongskommando som forsvinn ved omstart.

Viss UFW eig politikken, uttrykkjer rutereglane videresending for eit par av kjelde, mål og grensesnitt. Dei er skilde frå inngåande reglar som opnar ei teneste på sjølve 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

Grensesnittnamnet er den faktiske overlay-eininga på den verten, som du kan lese med ip link; det er ikkje ein fast streng på tvers av installasjonar. Viss verten videresender som standard og UFW ikkje er i vegen, vert ruteregelen ignorert, og det er kjerneinnstillingane som tel.

Vel korleis svar kjem tilbake

Med kjeldelagring ser LAN-tenesta den verkelege overlay-adressa og svarar på ho. Det krev ei rute på LAN-verten eller rutaren hans som peikar overlay-prefikset mot gatewayen din, og det er ei endring utanfor Linux-boksen.

Når den ruta ikkje kan leggjast til, får avgrensa kjeldeomsetjing førespurnaden til å sjå ut som han kom frå gatewayen på LAN-et. Svara kjem då tilbake lokalt, og det trengst inga endring i LAN-rutinga, men prisen er at den opphavlege kjelda forsvinn frå tenesteloggene.

Avgrens omsetjinga til overlay-kjelda og den spesifikke LAN-destinasjonen. Å omsetje alt som forlèt LAN-grensesnittet er den breie versjonen som seinare overraskar kven som helst som les reglane, og han skjuler også trafikk som burde vore blokkert.

Ingen av vala gjev ubeden tilgang frå LAN-et tilbake til vilkårlege overlay-medlemmar. Viss det er ønskt, er det ein eigen regel med si eiga gjennomgang.

Test frå eit ekte medlem

Kopla til frå eit anna medlem, ikkje frå gatewayen, og be om éi tillaten teneste. Prøv deretter ei teneste som skal halde seg stengd, og gjenta begge testane etter ei ny tilkopling og etter ein omstart av gatewayen.

Eit medlem som rapporterer ONLINE, eller ein vellukka ping til overlay-adressa til gatewayen, validerer ikkje ruta, videresendingsregelen eller returvegen:

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

Den andre kommandoen viser kva grensesnitt pakken ville brukt til LAN-verten, og den tredje viser om ruteregelen finst i den forma du meinte. Viss begge ser rette ut og tenesta enno går ut på tid, er returvegen den gjenverande mistenkte.

Relaterte artiklar