Poistettu ZeroTier-jäsen palaa: peru valtuutus ensin
Verkossa oleva laite voi pyytää liittymistä uudelleen heti, kun sen tietue poistetaan. Peru valtuutus ja kohtele poistoa sen jälkeen luettelon siivouksena.
Poistat jäsenen, suljet sivun, ja päivää myöhemmin sama laite on taas paikalla. Se ei ole konsolin virhe. Näin käy, kun tietue poistetaan laitteen ollessa vielä verkossa ja pyytäessä yhä liittymistä.
Kaksi toimintoa sijaitsevat vierekkäin ja tekevät eri työt. Toinen päättää pääsystä, toinen vain siistii luetteloa.
Aloita tietueesta, joka palaa
Avaa verkko ja katso tietuetta, joka palasi. Kirjaa sen node ID, viimeisin osoite ja aika, jolloin se ilmestyi uudelleen. Vertaa sitä laitteeseen, jonka aioit poistaa käytöstä. Näyttönimi on se, mitä joku kirjoitti, ja osoite voi muuttua seuraavalla liittymiskerralla.
Node ID on vakaa tunniste. Verkon ID nimeää verkon, joten se kertoo, mitä luetteloa luet, eikä mitään siitä, mikä laite siinä on. Kirjaa molemmat ja vertaa sitten node ID:tä koneeseen, jonka aioit poistaa käytöstä.
Jos vertaat väärin, poistat toimivan koneen, kun taas ei-toivottu jatkaa pyytämistä. Silloin luettelo näyttää oikealta yhden päivän ajan. Se on tarpeeksi kauan, ettei kukaan huomaa, ja juuri siinä on ongelma.
Peru valtuutus ennen poistamista
Muuta ensin valtuutuksen tilaa ohjaimen tukemalla työnkululla. Siitä hetkestä lähtien liittymisyritys näkyy valtuuttamattomana sen sijaan, että se palauttaisi pääsyn hiljaa, ja pyyntö on näkyvä eikä näkymätön.
Poisto tulee jälkeen, ei koskaan sen sijaan. Valtuutetun jäsenen tietueen poistaminen ei jätä mitään peruttavaa. Laite kysyy uudelleen, ja ohjain kohtelee sitä uutena.
Koneelle, jota vielä hallitset, verkosta lähteminen on hyödyllinen osa käytöstä poistoa. Se ei korvaa ylläpitäjän päätöstä kadonneesta laitteesta. Asiakasohjelma, jota et enää hallitse, voi jättää huomiotta kaiken, mitä sille on sanottu.
Missä kaksi toimintoa sijaitsevat
Isännöidyllä ohjaimella jäsenluettelo tarjoaa molemmat toiminnot ja merkitsee ne riittävän selvästi, jotta ne erottaa. Itse isännöidyllä ohjaimella sama ero näkyy API:ssa ja paikallisessa kokoonpanossa, ja juuri siitä hämmennys yleensä alkaa.
# 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"
Nämä kaksi kutsua riittävät osoittamaan, oliko jäsen koskaan todella valtuuttamaton. Tietue, joka palaa yhä uudelleen arvolla authorized: true, ei ollut koskaan peruttu; se vain poistettiin.
Vahvista resurssista, älä luettelosta
Siisti jäsenluettelo ei ole pääsyn tarkistus. Kokeile resurssia, jota laite käytti aiemmin, siltä laitteelta tai koneelta, jolla on sen vanha osoite, ja vahvista, että yhteys epäonnistuu. Vahvista sitten, että hyväksytty korvaaja toimii edelleen.
Sisällytä reitit ja palveluiden käyttöoikeudet tuohon testiin. ZeroTier voi valtuuttaa jäsenen ja jättää sen silti pääsemättä hallittuun reittiin. Sovelluksen käyttöoikeus voi epäonnistua samalla tavalla. Molemmat näyttävät jäsenluettelosta samalta.
zerotier-cli listnetworks
ip route show | grep zt
ping -c 3 10.144.0.5
Itse isännöidylle ohjaimelle pidä johdonmukainen varmuuskopio sen identiteetistä ja kokoonpanosta. Palautus, joka palaa aiempaan tilaan, voi tuoda vanhan valtuutuksen mukanaan, ja jäsenluettelo näyttää täsmälleen samalta kuin ennen käytöstä poistoa.
Käytöstä poisto on valmis, kun vanha identiteetti ei pääse mihinkään ja tietue on poissa. Tee ne tässä järjestyksessä, niin jäsen lakkaa palaamasta.