Forigita ZeroTier-ano revenas: unue nuligu la rajtigon

Enreta aparato povas denove peti aliĝon tuj kiam ĝia rikordo estas forigita. Nuligu la rajtigon, poste traktu la forigon kiel purigadon de la listo.

Vi forigas la anon, fermas la paĝon, kaj unu tagon poste la sama aparato estas reen. Tio ne estas cimo en la konzolo. Tio okazas kiam rikordo estas forigita dum la aparato ankoraŭ estas enreta kaj ankoraŭ petas aliĝon.

Du operacioj staras unu apud la alia kaj faras malsamajn taskojn. Unu decidas pri aliro, la alia nur ordigas la liston.

Komencu ĉe la rikordo, kiu revenas

Malfermu la reton kaj rigardu la eron, kiu revenis. Notu ĝian node ID, ĝian lastan adreson kaj la tempon, kiam ĝi reaperis. Komparu tion kun la aparato, kiun vi intencis eksigi. Montra nomo estas tio, kion iu tajpis, kaj la adreso povas ŝanĝiĝi ĉe la sekva aliĝo.

La node ID estas la stabila identigilo. Reta ID nomigas la reton, do ĝi diras al vi, kiun liston vi legas, kaj nenion pri tio, kiu aparato estas en ĝi. Notu ambaŭ, poste kunigu la node ID kun la maŝino, kiun vi intencis eksigi.

Se vi eraras pri tiu komparo, vi forigos funkciantan maŝinon dum la nedezirata daŭre petas. Tiam la listo ŝajnas ĝusta dum unu tago. Tio sufiĉas por ke neniu rimarku, kaj ĝuste tio estas la problemo.

Nuligu antaŭ ol forigi

Unue ŝanĝu la rajtigan staton per la laborfluo, kiun la regilo subtenas. De tiu punkto, aliĝprovo aperas kiel ne rajtigita anstataŭ silente restarigi aliron, kaj la peto estas videbla anstataŭ nevidebla.

La forigo venas poste, neniam anstataŭe. Forigi la rikordon de rajtigita ano lasas nenion por nuligi. La aparato denove demandas, kaj la regilo traktas ĝin kiel nova.

Por maŝino, kiun vi ankoraŭ regas, forlasi la reton estas utila parto de eksigo. Ĝi ne anstataŭas la decidon de la administranto pri perdita aparato. Kliento, kiun vi ne plu regas, povas ignori tion, kion oni diris al ĝi.

Kie loĝas la du operacioj

Ĉe gastigita regilo, la membrolisto ofertas ambaŭ agojn kaj etikedas ilin sufiĉe klare por distingi. Ĉe memgastigita regilo, la sama distingo aperas en la API kaj en la loka agordo, kaj ĝuste tie kutime komenciĝas la konfuzo.

# list members with authorization state
curl -s -H "X-ZT1-Auth: $TOKEN" \
  "http://127.0.0.1:9993/controller/network/$NETWORK_ID/member" | jq 'to_entries[] | {id: .key, authorized: .value.authorized}'

# deauthorize one member by node id, then confirm
curl -s -X POST -H "X-ZT1-Auth: $TOKEN" -d '{"authorized": false}' \
  "http://127.0.0.1:9993/controller/network/$NETWORK_ID/member/$NODE_ID"

Tiuj du vokoj sufiĉas por montri, ĉu la ano iam efektive estis ne rajtigita. Rikordo, kiu daŭre revenas kun authorized: true neniam estis nuligita; ĝi estis nur forigita.

Konfirmu per la rimedo, ne per la listo

Ordigita membrolisto ne estas alirkontrolo. Provu la rimedon, kiun la aparato uzis antaŭe, el tiu aparato aŭ el maŝino havanta ĝian malnovan adreson, kaj konfirmu, ke la konekto malsukcesas. Poste konfirmu, ke aprobita anstataŭaĵo ankoraŭ funkcias.

Inkluzivu itinerojn kaj servpermesojn en tiu testo. ZeroTier povas rajtigi anon kaj tamen lasi ĝin nekapabla atingi administritan itineron. Aplikpermeso povas malsukcesi same. Ambaŭ aspektas idente el la membrolisto.

zerotier-cli listnetworks
ip route show | grep zt
ping -c 3 10.144.0.5

Por memgastigita regilo, konservu konsekvencan sekurkopion de ĝia identeco kaj agordo. Restaŭro, kiu returniĝas al pli frua stato, povas reporti malnovan rajtigon, kaj la membrolisto aspektos precize kiel antaŭ la eksigo.

Eksigo finiĝas kiam la malnova identeco povas atingi nenion kaj la rikordo malaperis. Faru tion en tiu ordo kaj la ano ĉesas reveni.

Rilataj artikoloj