Dzēsts ZeroTier dalībnieks atgriežas: vispirms atsaucat atļauju

Jūs dzēšat dalībnieku, aizverat lapu, un dienu vēlāk tā pati ierīce atkal ir klāt. Tā nav konsoles kļūda. Tas notiek, kad ieraksts tiek dzēsts, kamēr ierīce vēl ir tiešsaistē un joprojām lūdz pievienoties.

Divas darbības atrodas blakus un dara dažādus darbus. Viena lemj par piekļuvi, otra tikai sakārto sarakstu.

Sāciet ar ierakstu, kas atgriežas

Atveriet tīklu un apskatiet atgriezušos ierakstu. Pierakstiet tā node ID, pēdējo adresi un laiku, kad tas atkal parādījās. Salīdziniet to ar ierīci, kuru grasījāties izņemt no ekspluatācijas. Rādītais nosaukums ir tas, ko kāds ievadīja, un adrese nākamajā pievienošanās reizē var mainīties.

Node ID ir stabilais identifikators. Tīkla ID piešķir tīklam nosaukumu, tāpēc tas pasaka, kuru sarakstu jūs lasāt, un neko par to, kura ierīce tajā ir. Pierakstiet abus, pēc tam saskaņojiet node ID ar mašīnu, kuru grasījāties izņemt no ekspluatācijas.

Ja šo salīdzinājumu izdarīsiet nepareizi, jūs noņemsiet strādājošu mašīnu, kamēr nevēlamā ierīce turpinās lūgt. Tad saraksts dienu izskatās pareizi. Tas ir pietiekami ilgi, lai neviens to nepamanītu, un tieši tā ir problēma.

Atsaucat pirms dzēšanas

Vispirms mainiet atļaujas stāvokli, izmantojot kontrollera atbalstīto darbplūsmu. No tā brīža pievienošanās mēģinājums parādās kā neautorizēts, nevis klusi atjauno piekļuvi, un pieprasījums ir redzams, nevis neredzams.

Dzēšana nāk pēc tam, nekad tās vietā. Noņemot autorizēta dalībnieka ierakstu, nepaliek nekas, ko atsaukt. Ierīce jautā vēlreiz, un kontrolleris to uzskata par jaunu.

Mašīnai, kuru vēl kontrolējat, tīkla atstāšana ir noderīga izņemšanas daļa. Tā neaizstāj administratora lēmumu par pazaudētu ierīci. Klientu, kuru vairs nekontrolējat, var neņemt vērā visu, kas tam tika teikts.

Kur atrodas abas darbības

Hostētā kontrollerī dalībnieku saraksts piedāvā abas darbības un marķē tās pietiekami skaidri, lai tās atšķirtu. Pašhostētā kontrollerī tā pati atšķirība parādās API un vietējā konfigurācijā, un parasti tieši tur sākas apjukums.

# 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"

Šie divi izsaukumi ir pietiekami, lai parādītu, vai dalībnieks kādreiz tiešām bija neautorizēts. Ieraksts, kas atkal un atkal atgriežas ar authorized: true vērtību, nekad netika atsaukts; tas tika vienkārši dzēsts.

Pārbaudiet no resursa, nevis no saraksta

Sakārtots dalībnieku saraksts nav piekļuves pārbaude. Izmēģiniet resursu, ko ierīce izmantoja agrāk, no šīs ierīces vai no mašīnas, kurai ir tās vecā adrese, un apstipriniet, ka savienojums neizdodas. Pēc tam apstipriniet, ka apstiprināts aizvietotājs joprojām darbojas.

Iekļaujiet šajā testā maršrutus un pakalpojumu atļaujas. ZeroTier var autorizēt dalībnieku un tomēr neļaut tam sasniegt pārvaldītu maršrutu. Lietojumprogrammas atļauja var neizdoties tāpat. No dalībnieku saraksta abi izskatās vienādi.

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

Pašhostētam kontrollerim uzturiet konsekventu tā identitātes un konfigurācijas dublējumu. Atjaunošana, kas atgriežas agrākā stāvoklī, var līdzi atnest vecu atļauju, un dalībnieku saraksts izskatīsies tieši tāpat kā pirms izņemšanas.

Izņemšana ir pabeigta, kad vecā identitāte neko nevar sasniegt un ieraksts ir pazudis. Dariet to šādā secībā, un dalībnieks pārstās atgriezties.