ZeroTier na ’n LAN: UFW-roetereëls, nie ’n poorttoelating nie

Om ’n drukker op die kantoor-LAN deur ’n ZeroTier-lid te bereik klink na een reël, maar dit is eintlik drie besluite op drie verskillende plekke. Die overlay moet weet waar die LAN is, die Linux-gasheer moet bereid wees om pakkette deur te stuur, en die LAN moet weet hoe om die antwoord terug te stuur. ’n Inkomende reël wat ’n poort op die gateway oopmaak, raak nie een van dié nie. Dit is die verkeerde gereedskap op die regte gasheer.

Drie take, drie eienaars

Die bestuurde roete hoort by die ZeroTier-netwerkkonfigurasie. Dit sê vir lede dat ’n voorvoegsel deur ’n bepaalde lidadres bereikbaar is.

Deurvoer hoort by die Linux-kern en by wie ook al die firewallbeleid besit. Dit besluit of ’n pakket wat op die overlay aankom, weer op die fisiese koppelvlak vertrek. ’n Gasheer wat nie deurstuur nie, laat die pakket stilweg val nadat dit dit aanvaar het. Die sender sien ’n tydverstreke fout en niks verskyn in die dienslog nie.

Die terugpad hoort by die LAN. Sy gashere en sy roeteerder moet weet dat die overlay-voorvoegsel deur jou gateway se LAN-adres bereikbaar is, of iets moet die verkeer vertaal sodat die vraag nooit ontstaan nie.

Elkeen van dié kan korrek wees terwyl die ander misluk, en daarom bewys ’n toets wat net die gateway ping niks oor die diens daar agter nie.

Rig die bestuurde roete op die lid

Voeg ’n roete vir die beoogde LAN-voorvoegsel by deur die gateway se overlay-adres, nie deur sy LAN-adres nie. Die overlay-adres is die een wat ander lede kan bereik; die LAN-adres is net op die draad betekenisvol.

Lede moet bestuurde roetes aanvaar voordat die ontwerp werk, en hul eie plaaslike netwerke mag nie reeds die voorvoegsel gebruik wat jy adverteer nie. ’n Afstandskootrekenaar wat tuis op 192.168.60.0/24 sit, kan nie ook 192.168.60.0/24 deur die overlay roeteer nie.

Hou die geadverteerde voorvoegsel so smal as wat die taak toelaat. Om ’n groter samevatting te adverteer om voorkeur te beïnvloed, kan ook adresruimte opeis wat nie joune is nie, en die gevolglike konflik verskyn op die toestelle wat aan albei netwerke koppel. Dit kan ook ’n lid laat verkies om ’n pad te volg wat nêrens heen lei nie. Hou die roete eerlik en laat beleid die res doen.

Skryf die voorvoegsel en die lidadres in dieselfde nota as die firewallreëls, want die mees algemene fout is ’n roete wat na die verkeerde lid wys.

Aktiveer deurvoer in die kern

Lees die lopende deurvoerwaarde voordat jy iets verander, en maak die instelling dan permanent deur die meganisme wat jou stelsel reeds gebruik, nie deur ’n eenmalige opdrag wat by herbegin verdwyn nie.

As UFW die beleid besit, druk sy roetereëls deurvoer uit vir ’n bron-, bestemming- en koppelvlakpaar. Dié is apart van inkomende reëls wat ’n diens op die gateway self oopmaak:

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

Die koppelvlaknaam is die werklike overlay-toestel op daardie gasheer, wat jy uit ip link kan lees; dit is nie ’n vaste string oor installasies nie. As die gasheer by verstek deurstuur en UFW nie in die pad is nie, sal die roetereël geïgnoreer word en die kerninstellings is wat saak maak.

Kies hoe antwoorde terugkom

Met bronbehoud sien die LAN-diens die werklike overlay-adres en antwoord daarop. Dit vereis ’n roete op die LAN-gasheer of sy roeteerder wat die overlay-voorvoegsel na jou gateway wys, en dit is ’n verandering buite die Linux-boks.

Wanneer daardie roete nie bygevoeg kan word nie, laat beperkte bronvertaling die versoek lyk asof dit van die gateway op die LAN kom. Antwoorde kom dan plaaslik terug en geen LAN-roeteverandering is nodig nie, teen die prys dat die oorspronklike bron in die dienslog verlore gaan.

Beperk die vertaling tot die overlay-bron en die spesifieke LAN-bestemming. Om alles te vertaal wat die LAN-koppelvlak verlaat, is die breë weergawe wat later vir elkeen wat die reëls lees verras, en dit verberg ook verkeer wat geblokkeer moes gewees het.

Nie een van die twee keuses verleen ongevraagde toegang van die LAN terug na willekeurige overlay-lede nie. As dit verlang word, is dit ’n aparte reël met sy eie hersiening.

Toets van ’n werklike lid af

Koppel van ’n ander lid, nie van die gateway nie, en vra een toegelate diens. Probeer dan ’n diens wat gesluit moet bly, en herhaal albei toetse ná ’n herverbinding en ná ’n herbegin van die gateway.

’n Lid wat as AANLYN rapporteer, of ’n suksesvolle ping na die gateway se overlay-adres, bekragtig nie die roete, die deurvoerreël of die terugpad nie:

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

Die tweede opdrag wys watter koppelvlak die pakket vir die LAN-gasheer sou gebruik, en die derde wys of die roetereël in die vorm bestaan wat jy bedoel het. As albei reg lyk en die diens nog steeds tyd verstryk, is die terugpad die oorblywende verdagte.