Ĉu la elireja nodo de ZeroTier ne funkcias? Kontrolu itineron, NAT kaj klienton

La itinera tabelo montras defaŭltan itineron tra la ZeroTier-interfaco, la reto raportas sin enlinea, kaj retumilo ankoraŭ eliras el la loka ISP-adreso. Tiu kombinaĵo oftas kaj ne estas eraro de la kliento. Defaŭlta itinero nur diras, kien la pakoj iru; io devas plusendi kaj traduki ilin ĉe la alia fino. Tri apartaj partoj devas esti veraj antaŭ ol elireja nodo funkcias.

La itinero ekzistas, sed nenio eliras

Unue kontrolu la itineran tabelon de la kliento. Linio kiel default via 10.147.20.5 dev zt0 pruvas, ke la itinero instaliĝis, ne ke la celo akceptos la trafikon. La sekva salteto devas esti membro preta kaj kapabla plusendi ĝin.

Se la sama peto ankoraŭ eliras tra la fizika interfaco, la kliento ne instalis la itineron, aŭ instalis ĝin kun metriko, kiu perdis kontraŭ la loka defaŭlto. Se la peto malaperas post la instalado de la itinero, la elireja membro ricevas pakojn kaj malsukcesas plusendi aŭ traduki ilin. Kliento, kiu konservas la fizikan defaŭlton, tute ne sendas pakon al la elirejo.

Tiu distingo decidas, kie labori. Komparo de publika adreso antaŭ kaj post la ŝanĝo apartigas itineron neniam uzitan de unu uzita kaj forĵetita, kaj ĝi postulas unu komandon anstataŭ revizio de la tuta agordo. Faru la komparon antaŭ ol ŝanĝi ion alian, por ke ambaŭ rezultoj venu el la sama komenca stato.

Tri partoj, kiuj ĉiuj devas esti veraj

Elirejo estas ĉeno, kaj la plej malforta ligilo difinas la simpton. La suba tabelo listigas la ligilojn laŭ la ordo, en kiu ili kutime malsukcesas.

La unua vico estas tiu, kiun la nomo de la opcio kaŝas. Membro fariĝas elirejo nur kiam ĝia kerno plusendas pakojn inter la ZeroTier-interfaco kaj la interfaco turnita al la interreto, kaj kiam la responda vojo tradukiĝas reen al la tunelo. Sen tiu plusendado, la membro estas samtavolano, ne enirejo.

La vico de la regilo estas rajtigo, ne agordo. Anonci 0.0.0.0/0 tra membro diras al ĉiu kliento, kie estas la elirejo; ĝi ne igas tiun membron kapabla porti la trafikon. Ĝi ankaŭ ne certigas, ke la membro havas funkciantan vojon al la interreto. La dokumentaro de ZeroTier pri elireja nodo kovras la saman disigon inter nodo, itinero kaj kliento.

Agordi la elirejan nodon por plusendi kaj traduki

Ŝaltu IPv4-plusendadon daŭre, poste aldonu fontan NAT por trafiko lasanta la WAN-interfacon. La filtroreguloj devas permesi la plusenditan fluon en ambaŭ direktojn, ĉar plusendado kaj tradukado apartas de permeso:

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

Anstataŭigu zt0 kaj eth0 per la nomoj sur la gastiganto; regulo konservita por ekzempla interfaco ne sekvas pakojn sur reala. Faru la ŝanĝojn daŭraj per la fajroŝirmila administrilo, kiu posedas la regulojn, ĉar komando en interaga ŝelo malaperas ĉe la sekva restarto.

Se la gastiganto rulas fajroŝirmilan administrilon kiel UFW aŭ firewalld, aldonu la regulojn per tiu administrilo anstataŭ staki iptables-liniojn apude. Du posedantoj redaktantaj la samajn ĉenojn produktas politikon dependan de la starta ordo. La ordo gravas, kiam la administrilo generas proprajn ĉenojn. Testu de kliento post reŝarĝi la administrilon, ne antaŭe.

Anoncu la itineron kaj akceptu ĝin en la kliento

Sur la reta regilo aldonu administritan itineron por 0.0.0.0/0, kies sekva salteto estas la ZeroTier-adreso de la elireja membro. Poste, sur la membro, kiu devus uzi ĝin, permesu la superregadon por tiu reto. La permeso estas loka: ĝi ne reagordas aliajn membrojn kaj ne ŝanĝas la regilon.

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

La lasta komando devus raporti la ZeroTier-interfacon kaj la adreson de la elireja membro. Se ĝi ankoraŭ raportas la fizikan interfacon, la itinero mankas aŭ konkurenca defaŭlto havas pli bonan metrikon.

Tenu la agordon limigita al la reto, kiu bezonas ĝin. Ŝalti akcepton de la defaŭlta itinero tutmonde, aŭ en reto, kiu devus provizi nur privatan subreton, sendas trafikon tra elirejo, kiu neniam estis dimensiita por tio.

Kontrolu la elirejon kaj la aliajn adresfamiliojn

Petu publikan adreson de servo, kiu raportas la fonton, kaj komparu ĝin kun la WAN-adreso de la elireja nodo. Poste ŝargu nomitan retejon por konfirmi, ke DNS ankoraŭ solvas, kaj testu unu gravan aplikaĵon anstataŭ nur retumilon.

Kliento kun duobla stako povas daŭre uzi sian denaskan IPv6-vojon, dum IPv4 eliras tra ZeroTier. Se la celo estas kaŝi aŭ regi la tutan trafikon, necesas aparta ::/0-itinero kaj IPv6-plusendado sur la elirejo, kaj IPv4-testo diras nenion pri ili.

La inversa voja filtrado de Linux povas ankaŭ forĵeti validan elirejan trafikon en la kliento. ZeroTier dokumentas konsideron pri rp_filter por partoprenantaj membroj; ŝanĝu tiun agordon intence kaj nur post kiam la itinero kaj NAT estas konfirmitaj, ne kiel la unua eksperimento.

Se la postulo estas aliro al NAS aŭ al unu oficeja subreto, administrita itinero por tiu prefikso estas pli malgranda kaj pli sekura ŝanĝo ol plena elirejo. Sendi la tutan retumadon tra alia aparato estas malsama decido ol atingi unu privatan rimedon, kaj ĝi meritas apartan revizion.