Verwijderd ZeroTier-lid komt terug: trek eerst de autorisatie in

Je verwijdert het lid, sluit de pagina en een dag later is hetzelfde apparaat terug. Dat is geen bug in de console. Dat gebeurt wanneer een record wordt verwijderd terwijl het apparaat nog online is en nog steeds om toelating vraagt.

Twee bewerkingen staan naast elkaar en doen verschillend werk. De ene beslist over toegang, de andere ruimt alleen de lijst op.

Begin bij het record dat terugkomt

Open het netwerk en bekijk de vermelding die terugkwam. Noteer het node ID, het laatste adres en het tijdstip waarop het weer verscheen. Vergelijk dat met het apparaat dat je wilde uitfaseren. Een weergavenaam is wat iemand heeft getypt, en het adres kan bij de volgende toetreding veranderen.

Het node ID is de stabiele identificatie. Een netwerk-ID geeft het netwerk een naam, dus het vertelt welke lijst je leest en niets over welk apparaat erin zit. Noteer beide en vergelijk daarna het node ID met de machine die je wilde uitfaseren.

Vergis je je in die vergelijking, dan verwijder je een werkende machine terwijl het ongewenste apparaat blijft vragen. De lijst ziet er dan een dag correct uit. Dat is lang genoeg dat niemand het merkt, en dat is precies het probleem.

Trek in voordat je verwijdert

Wijzig eerst de autorisatiestatus via de werkwijze die de controller ondersteunt. Vanaf dat moment verschijnt een toetredingspoging als niet-geautoriseerd in plaats van stilzwijgend toegang te herstellen, en het verzoek is zichtbaar in plaats van onzichtbaar.

Het verwijderen komt daarna, nooit in plaats daarvan. Het record van een geautoriseerd lid weghalen laat niets over om in te trekken. Het apparaat vraagt opnieuw, en de controller behandelt het als nieuw.

Voor een machine die je nog beheert, is het netwerk verlaten een nuttig onderdeel van uitfaseren. Het vervangt niet de beslissing van de beheerder over een verloren apparaat. Een client die je niet meer beheert, kan negeren wat er ook tegen is gezegd.

Waar de twee bewerkingen zitten

Op een gehoste controller biedt de ledenlijst beide acties en labelt ze duidelijk genoeg om ze te onderscheiden. Op een zelf gehoste controller verschijnt hetzelfde onderscheid in de API en in de lokale configuratie, en daar begint de verwarring meestal.

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

Die twee aanroepen zijn genoeg om te laten zien of het lid ooit echt niet-geautoriseerd was. Een record dat steeds terugkomt met authorized: true is nooit ingetrokken; het is alleen verwijderd.

Controleer vanuit de resource, niet de lijst

Een opgeruimde ledenlijst is geen toegangscontrole. Probeer de resource die het apparaat eerder gebruikte, vanaf dat apparaat of vanaf een machine met het oude adres, en bevestig dat de verbinding mislukt. Bevestig daarna dat een goedgekeurde vervanging nog werkt.

Neem routes en servicerechten op in die test. ZeroTier kan een lid autoriseren en het alsnog niet in staat stellen een beheerde route te bereiken. Een applicatierecht kan op dezelfde manier falen. Vanuit de ledenlijst zien beide er identiek uit.

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

Houd voor een zelf gehoste controller een consistente back-up van zijn identiteit en configuratie. Een herstel dat terugrolt naar een eerdere toestand kan een oude autorisatie meebrengen, en de ledenlijst ziet er precies zo uit als voor het uitfaseren.

Het uitfaseren is klaar wanneer de oude identiteit niets meer kan bereiken en het record weg is. Doe dat in die volgorde en het lid komt niet meer terug.