Usunięty członek ZeroTier wraca: najpierw cofnij autoryzację

Usuwasz członka, zamykasz stronę, a dzień później to samo urządzenie znów tu jest. To nie błąd konsoli. Tak dzieje się, gdy rekord zostaje usunięty, podczas gdy urządzenie jest jeszcze w sieci i wciąż prosi o dołączenie.

Dwie operacje leżą obok siebie i robią różne rzeczy. Jedna decyduje o dostępie, druga tylko porządkuje listę.

Zacznij od rekordu, który wraca

Otwórz sieć i spójrz na wpis, który wrócił. Zanotuj jego node ID, ostatni adres i czas, w którym pojawił się ponownie. Porównaj to z urządzeniem, które chciałeś wycofać. Wyświetlana nazwa to to, co ktoś wpisał, a adres może się zmienić przy następnym dołączeniu.

Node ID to stabilny identyfikator. ID sieci nazywa sieć, więc mówi, którą listę czytasz, i nic o tym, które urządzenie w niej jest. Zanotuj oba, a potem dopasuj node ID do maszyny, którą chciałeś wycofać.

Jeśli pomylisz to porównanie, usuniesz działającą maszynę, podczas gdy niechciane urządzenie nadal prosi. Lista wygląda wtedy poprawnie przez jeden dzień. To dość długo, by nikt tego nie zauważył, i właśnie w tym jest problem.

Cofnij, zanim usuniesz

Najpierw zmień stan autoryzacji przez przepływ pracy obsługiwany przez kontroler. Od tego momentu próba dołączenia pojawia się jako nieautoryzowana, zamiast po cichu przywracać dostęp, a żądanie jest widoczne, a nie niewidoczne.

Usunięcie przychodzi potem, nigdy zamiast. Usunięcie rekordu autoryzowanego członka nie zostawia niczego do cofnięcia. Urządzenie pyta ponownie, a kontroler traktuje je jako nowe.

Dla maszyny, którą nadal kontrolujesz, opuszczenie sieci jest pożyteczną częścią wycofywania. Nie zastępuje decyzji administratora o utraconym urządzeniu. Klient, którego już nie kontrolujesz, może zignorować wszystko, co mu powiedziano.

Gdzie są obie operacje

Na hostowanym kontrolerze lista członków oferuje obie akcje i oznacza je dość jasno, by je rozróżnić. Na kontrolerze hostowanym samodzielnie ta sama różnica pojawia się w API i w lokalnej konfiguracji, i tam zwykle zaczyna się zamieszanie.

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

Te dwa wywołania wystarczą, by pokazać, czy członek kiedykolwiek naprawdę był nieautoryzowany. Rekord, który wciąż wraca z authorized: true, nigdy nie został cofnięty; został tylko usunięty.

Sprawdź na zasobie, nie na liście

Uporządkowana lista członków nie jest kontrolą dostępu. Wypróbuj zasób, którego urządzenie używało wcześniej, z tego urządzenia lub z maszyny mającej jego stary adres, i potwierdź, że połączenie zawodzi. Potem potwierdź, że zatwierdzony zamiennik nadal działa.

Uwzględnij w tym teście trasy i uprawnienia usług. ZeroTier może autoryzować członka i mimo to nie pozwolić mu dotrzeć do zarządzanej trasy. Uprawnienie aplikacji może zawieść w ten sam sposób. Oba przypadki wyglądają identycznie z poziomu listy członków.

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

Na kontrolerze hostowanym samodzielnie utrzymuj spójną kopię zapasową jego tożsamości i konfiguracji. Przywrócenie do wcześniejszego stanu może przynieść ze sobą starą autoryzację, a lista członków będzie wyglądać dokładnie jak przed wycofaniem.

Wycofanie jest zakończone, gdy stara tożsamość nie może niczego osiągnąć, a rekordu nie ma. Zrób to w tej kolejności, a członek przestanie wracać.