Tabelul de rutare arată o rută implicită prin interfața ZeroTier, rețeaua se raportează online, iar browserul iese în continuare pe adresa locală a furnizorului. Această combinație este obișnuită și nu este o eroare a clientului. O rută implicită spune doar unde trebuie să meargă pachetele; ceva trebuie să le redirecționeze și să le traducă la celălalt capăt. Trei părți separate trebuie să fie adevărate înainte ca un nod de ieșire să funcționeze.

Ruta există, dar nimic nu iese

Verificați mai întâi tabelul de rutare al clientului. O linie precum default via 10.147.20.5 dev zt0 dovedește că ruta a fost instalată, nu că destinația va accepta traficul. Următorul salt trebuie să fie un membru dispus și capabil să o redirecționeze.

Dacă aceeași cerere iese în continuare prin interfața fizică, clientul nu a instalat ruta sau a instalat-o cu o metrică ce a pierdut în fața rutei implicite locale. Dacă cererea dispare după instalarea rutei, membrul de ieșire primește pachete și nu reușește să le redirecționeze sau să le traducă. Un client care păstrează ruta implicită fizică nu trimite niciun pachet către ieșire.

Această distincție decide unde se lucrează. Compararea unei adrese publice înainte și după modificare separă o rută niciodată folosită de una folosită și apoi abandonată, și cere o singură comandă în locul unei revizuiri a întregii configurații. Faceți comparația înainte de a schimba orice altceva, ca ambele rezultate să provină din aceeași stare inițială.

Trei părți care trebuie toate adevărate

O ieșire este un lanț, iar veriga cea mai slabă stabilește simptomul. Tabelul de mai jos enumeră verigile în ordinea în care eșuează de obicei.

PartWhere it livesWhat a failure looks like
Forwarding and NATExit node kernel and firewallTraffic arrives, no reply
Managed default routeZeroTier network controllerNo default via the tunnel on the member
Client acceptanceMember's per-network settingRoute offered but not installed
DNS behaviorClient resolver configurationPages fail by name, IP works

Primul rând este cel pe care numele opțiunii îl ascunde. Un membru devine ieșire doar când nucleul său redirecționează pachete între interfața ZeroTier și interfața orientată spre internet, și când calea de răspuns este tradusă înapoi în tunel. Fără acea redirecționare, membrul este un egal, nu o poartă.

Rândul controlerului este autorizare, nu configurare. Anunțarea 0.0.0.0/0 printr-un membru spune fiecărui client unde este ieșirea; asta nu face membrul capabil să transporte traficul. Nu verifică nici că membrul are o cale funcțională spre internet. Documentația ZeroTier despre nodul de ieșire acoperă aceeași separare între nod, rută și client.

Configurați nodul de ieșire să redirecționeze și să traducă

Activați redirecționarea IPv4 în mod persistent, apoi adăugați NAT de sursă pentru traficul care părăsește interfața WAN. Regulile de filtrare trebuie să permită fluxul redirecționat în ambele direcții, deoarece redirecționarea și traducerea sunt separate de permisiune:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -A FORWARD -i zt0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o zt0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

Înlocuiți zt0 și eth0 cu numele de pe gazdă; o regulă salvată pentru o interfață exemplu nu urmărește pachetele pe una reală. Faceți modificările persistente prin managerul de firewall care deține regulile, deoarece o comandă într-un shell interactiv dispare la următoarea repornire.

Dacă gazda rulează un manager de firewall precum UFW sau firewalld, adăugați regulile prin acel manager în loc să stivuiți linii iptables alături. Doi proprietari care editează aceleași lanțuri produc o politică dependentă de ordinea de pornire. Ordinea contează când managerul își generează propriile lanțuri. Testați de la un client după reîncărcarea managerului, nu înainte.

Anunțați ruta și acceptați-o pe client

Pe controlerul de rețea adăugați o rută gestionată pentru 0.0.0.0/0 al cărei următor salt este adresa ZeroTier a membrului de ieșire. Apoi, pe membrul care ar trebui să o folosească, permiteți suprascrierea pentru acea rețea. Permisiunea este locală: nu reconfigurează alți membri și nu schimbă controlerul.

zerotier-cli listnetworks
zerotier-cli set <network-id> allowDefault=1
ip route get 1.1.1.1

Ultima comandă ar trebui să raporteze interfața ZeroTier și adresa membrului de ieșire. Dacă raportează în continuare interfața fizică, ruta lipsește sau o rută implicită concurentă are o metrică mai bună.

Țineți setarea limitată la rețeaua care are nevoie de ea. Activarea acceptării rutei implicite global, sau într-o rețea care ar trebui să ofere doar o subrețea privată, trimite traficul printr-o ieșire care nu a fost niciodată dimensionată pentru asta.

Verificați ieșirea și examinați celelalte familii de adrese

Cereți o adresă publică de la un serviciu care raportează sursa și comparați-o cu adresa WAN a nodului de ieșire. Apoi încărcați un site după nume pentru a confirma că DNS-ul încă rezolvă, și testați o aplicație importantă, nu doar un browser.

Un client cu stivă dublă poate continua să folosească calea sa IPv6 nativă în timp ce IPv4 iese prin ZeroTier. Dacă scopul este să ascundeți sau să controlați tot traficul, sunt necesare o rută ::/0 separată și redirecționare IPv6 pe ieșire, iar un test IPv4 nu spune nimic despre ele.

Filtrarea inversă a căii în Linux poate de asemenea să arunce trafic de ieșire valid pe client. ZeroTier documentează o considerație rp_filter pentru membrii participanți; schimbați această setare deliberat și numai după confirmarea rutei și a NAT-ului, nu ca prim experiment.

Dacă cerința este accesul la un NAS sau la o subrețea de birou, o rută gestionată pentru acel prefix este o schimbare mai mică și mai sigură decât o ieșire completă. Trimiterea întregii navigări prin alt dispozitiv este o decizie diferită de a ajunge la o singură resursă privată, și merită o revizuire separată.

Articole similare