Slettet ZeroTier-medlem kommer tilbake: tilbakekall godkjenningen først

Du sletter medlemmet, lukker siden, og en dag senere er samme enhet tilbake. Det er ikke en feil i konsollen. Det er det som skjer når en post slettes mens enheten fortsatt er på nett og fortsatt ber om å bli med.

To operasjoner ligger side om side og gjør ulike jobber. Den ene avgjør tilgang, den andre rydder bare i listen.

Start med posten som kommer tilbake

Åpne nettverket og se på oppføringen som kom tilbake. Noter node ID-en, siste adresse og tidspunktet den dukket opp igjen. Sammenlign det med enheten du ville utfase. Et visningsnavn er det noen har skrevet, og adressen kan endres ved neste innmelding.

Node ID-en er den stabile identifikatoren. En nettverks-ID navngir nettverket, så den forteller hvilken liste du leser og ingenting om hvilken enhet som er i den. Noter begge, og sammenhold deretter node ID-en med maskinen du ville utfase.

Tar du feil i den sammenligningen, fjerner du en maskin som virker mens den uønskede fortsetter å spørre. Listen ser da riktig ut i en dag. Det er lenge nok til at ingen merker det, og det er nettopp problemet.

Tilbakekall før du sletter

Endre først godkjenningstilstanden gjennom arbeidsflyten kontrolleren støtter. Fra det punktet vises et innmeldingsforsøk som uautorisert i stedet for å gjenopprette tilgang i det stille, og forespørselen er synlig i stedet for usynlig.

Slettingen kommer etterpå, aldri i stedet. Fjerner du posten til et godkjent medlem, er det ingenting igjen å tilbakekalle. Enheten spør igjen, og kontrolleren behandler den som ny.

For en maskin du fortsatt kontrollerer, er det en nyttig del av utfasingen å forlate nettverket. Det er ikke en erstatning for administratorens beslutning om en tapt enhet. En klient du ikke lenger kontrollerer, kan ignorere hva den enn har fått beskjed om.

Hvor de to operasjonene ligger

På en driftet kontroller tilbyr medlemslisten begge handlingene og merker dem tydelig nok til å skilles. På en selvdriftet kontroller vises samme forskjell i API-et og i den lokale konfigurasjonen, og det er der forvirringen vanligvis starter.

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

Disse to kallene er nok til å vise om medlemmet noen gang faktisk var uautorisert. En post som stadig kommer tilbake med authorized: true ble aldri tilbakekalt; den ble bare slettet.

Bekreft fra ressursen, ikke listen

En ryddig medlemsliste er ikke en tilgangskontroll. Prøv ressursen enheten brukte før, fra den enheten eller fra en maskin som har dens gamle adresse, og bekreft at forbindelsen feiler. Bekreft deretter at en godkjent erstatning fortsatt virker.

Ta med ruter og tjenestetillatelser i den testen. ZeroTier kan godkjenne et medlem og likevel la det være ute av stand til å nå en administrert rute. En applikasjonstillatelse kan feile på samme måte. Begge ser like ut fra medlemslisten.

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

For en selvdriftet kontroller, hold en konsistent sikkerhetskopi av identiteten og konfigurasjonen. En gjenoppretting som ruller tilbake til en tidligere tilstand, kan bringe en gammel godkjenning med seg, og medlemslisten vil se nøyaktig ut som før utfasingen.

Utfasingen er ferdig når den gamle identiteten ikke kan nå noe og posten er borte. Gjør det i den rekkefølgen, og medlemmet slutter å komme tilbake.