ZeroTier către un LAN: reguli de rutare UFW, nu o permisiune de port

A ajunge la o imprimantă din LAN-ul biroului printr-un membru ZeroTier sună ca o singură regulă, dar de fapt sunt trei decizii în trei locuri diferite. Overlay-ul trebuie să știe unde este LAN-ul, hostul Linux trebuie să fie dispus să redirecționeze pachete, iar LAN-ul trebuie să știe cum să trimită răspunsul înapoi. O regulă de intrare care deschide un port pe gateway nu atinge niciuna dintre acestea. Este instrumentul greșit aplicat hostului corect.

Trei sarcini, trei responsabili

Ruta administrată aparține configurației de rețea ZeroTier. Ea le spune membrilor că un prefix este accesibil printr-o anumită adresă de membru.

Redirecționarea aparține nucleului Linux și celui care deține politica firewall-ului acestuia. Ea decide dacă un pachet care sosește pe overlay iese din nou prin interfața fizică. Un host care nu redirecționează va arunca pachetul în silențiu după ce îl acceptă. Expeditorul vede un timeout și nimic nu apare în jurnalul serviciului.

Calea de întoarcere aparține LAN-ului. Hosturile și routerul acestuia trebuie să știe că prefixul overlay-ului este accesibil prin adresa LAN a gateway-ului dvs., sau ceva trebuie să traducă traficul astfel încât întrebarea să nu apară niciodată.

Fiecare dintre acestea poate fi corectă în timp ce celelalte eșuează, și de aceea un test care doar face ping la gateway nu demonstrează nimic despre serviciul din spatele lui.

Îndreptați ruta administrată către membru

Adăugați o rută pentru prefixul LAN dorit prin adresa overlay a gateway-ului, nu prin adresa lui LAN. Adresa overlay este cea la care pot ajunge ceilalți membri; adresa LAN are sens doar pe cablu.

Membrii trebuie să accepte rutele administrate pentru ca proiectul să funcționeze, iar rețelele lor locale nu trebuie să folosească deja prefixul pe care îl anunțați. Un laptop aflat la distanță care acasă este pe 192.168.60.0/24 nu poate ruta nici el 192.168.60.0/24 prin overlay.

Păstrați prefixul anunțat cât mai îngust permite sarcina. Anunțarea unui agregat mai mare pentru a influența preferința poate revendica și spațiu de adrese care nu vă aparține, iar conflictul rezultat apare pe dispozitivele conectate la ambele rețele. Poate determina, de asemenea, un membru să prefere o cale care nu duce nicăieri. Păstrați ruta onestă și lăsați politica să facă restul.

Scrieți prefixul și adresa membrului în aceeași notă cu regulile firewall, pentru că cea mai frecventă defecțiune este o rută care indică membrul greșit.

Activați tranzitul în nucleu

Citiți valoarea de redirecționare în curs înainte de a schimba ceva, apoi faceți setarea permanentă prin mecanismul pe care sistemul dvs. îl folosește deja, nu printr-o comandă unică ce dispare la repornire.

Dacă UFW deține politica, regulile sale de rută exprimă redirecționarea pentru o pereche de sursă, destinație și interfață. Ele sunt separate de regulile de intrare care deschid un serviciu pe gateway-ul propriu-zis:

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

Numele interfeței este dispozitivul overlay real de pe acel host, pe care îl puteți citi cu ip link; nu este un șir fix în toate instalările. Dacă hostul redirecționează implicit și UFW nu este pe traseu, regula de rută va fi ignorată și contează setările nucleului.

Alegeți cum se întorc răspunsurile

Cu păstrarea sursei, serviciul din LAN vede adresa overlay reală și răspunde la ea. Asta necesită o rută pe hostul LAN sau pe routerul acestuia care să îndrepte prefixul overlay către gateway-ul dvs., iar aceasta este o schimbare în afara cutiei Linux.

Când acea rută nu poate fi adăugată, o traducere de sursă delimitată face cererea să pară că vine de la gateway-ul din LAN. Răspunsurile se întorc atunci local și nu este nevoie de nicio modificare a rutării LAN, cu prețul pierderii sursei originale în jurnalele serviciului.

Limitați traducerea la sursa overlay și la destinația LAN specifică. A traduce tot ce iese din interfața LAN este versiunea largă care mai târziu surprinde pe oricine citește regulile, și ascunde și traficul care ar fi trebuit blocat.

Nicio opțiune nu acordă acces nesolicitat din LAN către membri overlay arbitrari. Dacă se dorește asta, este o regulă separată cu propria revizuire.

Testați de pe un membru real

Conectați-vă de pe alt membru, nu de pe gateway, și solicitați un serviciu permis. Apoi încercați un serviciu care ar trebui să rămână închis și repetați ambele teste după o reconectare și după o repornire a gateway-ului.

Un membru care raportează ONLINE, sau un ping reușit la adresa overlay a gateway-ului, nu validează ruta, regula de redirecționare sau calea de întoarcere:

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

A doua comandă arată ce interfață ar folosi pachetul pentru hostul LAN, iar a treia arată dacă regula de rută există în forma pe care ați intenționat-o. Dacă ambele par corecte și serviciul încă expiră, calea de întoarcere este suspectul rămas.