Was der Agent gespeichert hat und wie Sie es leeren
Der Agent zeichnet die Systemänderungen auf, die er vornimmt, um sie später rückgängig machen zu können. Bleiben nach einem unsauberen Herunterfahren DNS-Einstellungen oder Routen zurück, prüfen Sie mit diesen Befehlen die Aufzeichnung und bringen die Maschine wieder in ihren Ausgangszustand.
Ein Verbindungsaufbau ändert Dinge außerhalb des Agenten: Die DNS-Konfiguration der Maschine wird umgestellt, Routen werden in die Routing-Tabelle eingetragen, Firewall-Regeln und -Ketten werden in den Kernel geladen. Jede dieser Änderungen wird vorher aufgezeichnet, damit sie beim Trennen rückgängig gemacht werden kann.
Diese Aufzeichnung ist der Zustand. Sie liegt in einer Datei, und jeder Eintrag ist nach dem benannt, was er rückgängig machen kann. Normalerweise rühren Sie sie nie an: Der Agent führt die Bereinigung beim Beenden selbst aus und erneut, wenn er startet, wenn sich das Gerät anmeldet und wenn es eine Verbindung herstellt. sxaccess store gibt es für den Fall, dass das nicht geschehen ist - die Maschine hat mitten in der Sitzung den Strom verloren, der Dienst wurde hart beendet, und der Tunnel ist weg, seine DNS-Einstellungen aber nicht.
Die CLI läuft unter Linux und macOS, deshalb geht es hier um diese beiden.
Was darin steht
Welche Einträge es gibt, hängt davon ab, was die Maschine tatsächlich benutzt hat. Unter macOS kommen nur dns_state, route_state und routeselector_state vor. Unter Linux nutzt der Agent eines der beiden Firewall-Backends, Sie sehen also normalerweise nur einen der beiden Einträge.
| Name | Was er rückgängig machen kann |
|---|---|
dns_state | Die DNS-Konfiguration der Maschine vor der Änderung durch den Tunnel. Fehlt, wenn start mit --disable-dns lief oder der Agent mit SX_USERSPACE_STACK=true läuft |
route_state | Routen, die in die Routing-Tabelle des Betriebssystems eingetragen wurden |
nftables_state | Über nftables geladene Firewall-Regeln, unter Linux |
iptables_state | Über iptables geladene Firewall-Regeln, Routing-Regeln, IP-Sets und Zugriffseinträge, unter Linux |
routeselector_state | Welche gerouteten Netze Sie mit sxaccess reach gewählt haben. Dieser Eintrag hat keinen eigenen Rücknahmeschritt: Er wird jedes Mal geschrieben, wenn die Auswahl angewendet wird, und bleibt nach dem Trennen bestehen; er steht daher normalerweise auch auf einer sauberen Maschine in der Liste |
Eine Maschine nach einem unsauberen Herunterfahren zurücksetzen
- 1
Erst nachsehen, dann eingreifen
store listliest nur. Der Befehl lässt sich jederzeit gefahrlos ausführen, auch im verbundenen Zustand, und ist der einzige hier ohne Folgen. Die Einträge erscheinen in keiner festen Reihenfolge.Alle diese Befehle kommunizieren mit dem Agenten, er muss also laufen - andernfalls starten Sie ihn mit
sudo sxaccess agent start. Beachten Sie, dass beim Start auch die Bereinigung ausgeführt wird: Auf einer Maschine, die sich selbst erholt hat, steht danach höchstensrouteselector_statein der Liste. Diese Seite gilt für den Fall, dass mehr darin steht.$ sxaccess store listStates the agent keeps:- dns_state- route_state- iptables_state- routeselector_state - 2
Zuerst die Verbindung trennen
Das Leeren wird abgelehnt, solange das Gerät verbunden ist oder gerade eine Verbindung aufbaut, und die Meldung sagt Ihnen, was zu tun ist:
stop the connection before clearing saved state: run 'sxaccess stop'. Trennen Sie die Verbindung, aber lassen Sie den Agenten laufen: Er erledigt die Arbeit.sxaccess stop - 3
Die gesamte Aufzeichnung zurücksetzen
reset --allführt den Rücknahmeschritt jedes Eintrags aus: DNS wird wiederhergestellt, hinzugefügte Routen werden entfernt, Firewall-Regeln werden abgebaut. Setzen Sie immer alles zurück und nie einzelne Einträge - warum, steht in der Warnung weiter unten.Verstehen Sie die ausgegebene Meldung nicht als Bilanz. Der Agent zählt die Einträge, die danach noch in der Aufzeichnung stehen: Ein Durchlauf, der alles rückgängig gemacht hat, gibt
Nothing was undoneaus, undSuccessfully reset 1 statesbedeutet meist, dass nurrouteselector_stateübrig ist, der keinen Rücknahmeschritt hat. Scheitert ein Rücknahmeschritt, endet der Befehl mitcould not undo the recorded changes: could not reset the saved states: …und behält diesen Eintrag für einen weiteren Versuch. So oder so: Prüfen Sie die Maschine selbst.sxaccess store reset --all - 4
Die Maschine prüfen, nicht die Liste
Ein Eintrag, dessen Rücknahmeschritt gelaufen ist, taucht in
store listnicht mehr auf; die Liste leert sich also, unabhängig davon, ob die zugrunde liegende Änderung wirklich rückgängig gemacht wurde. Sehen Sie an der Maschine selbst nach.Nichts sollte mehr über die Tunnel-Schnittstelle geroutet werden, auch nicht über Routen zu gerouteten Netzen, die Sie ausgewählt hatten und die außerhalb des Overlay-Bereichs liegen. Kein Resolver-Eintrag sollte den DNS-Server des Overlays nennen.
Unter Linux zeigt
ip route showdie Routen undresolvectl status | head -20die Resolver. Unter macOS verwenden Sienetstat -rn -f inetundscutil --dns | head -20. - 5
Wieder verbinden
Durch das Zurücksetzen geht nichts verloren. Der nächste Verbindungsaufbau nimmt dieselben Änderungen erneut vor und schreibt eine neue Aufzeichnung darüber.
sxaccess start
Befehle und Argumente
reset und drop erwarten beide genau einen Namen oder die Option --all (-a), nie beides und nie keins von beiden. Das bloße Wort all wird als Name eines Eintrags interpretiert, nicht als Option. reset <Name> meldet Erfolg, unabhängig davon, ob der Eintrag in der Datei stand, und akzeptiert nur Namen von Einträgen mit Rücknahmeschritt - routeselector_state wird abgelehnt. drop <Name> akzeptiert jeden Namen aus der Datei und scheitert bei einem, der dort nicht steht, mit no stored state named ….
| Befehl | Wirkung |
|---|---|
sxaccess store list | Nennt jeden gespeicherten Eintrag. Liest nur und ist auch im verbundenen Zustand gefahrlos |
sxaccess store reset --all | Führt den Rücknahmeschritt jedes Eintrags aus und leert dann die Aufzeichnung. Ein Eintrag, dessen Rücknahmeschritt scheitert, bleibt erhalten, und der Befehl meldet den Fehler; routeselector_state, der keinen Rücknahmeschritt hat, bleibt ebenfalls. Erfordert ein getrenntes Gerät |
sxaccess store reset <Name> | Macht diesen einen Eintrag rückgängig und schreibt die Aufzeichnung dann ohne die übrigen neu - alle anderen Einträge fallen weg, ohne rückgängig gemacht zu werden. Erfordert ein getrenntes Gerät |
sxaccess store drop --all | Verwirft die gesamte Aufzeichnung, ohne etwas rückgängig zu machen. Die gemeldete Zahl zählt auch bereits geleerte Einträge mit und kann daher höher sein als das, was store list zeigte. Erfordert ein getrenntes Gerät |
sxaccess store drop <Name> | Verwirft diesen Eintrag, ohne ihn rückgängig zu machen, und mit ihm den Rest der Aufzeichnung. Erfordert ein getrenntes Gerät |
Wo die Datei liegt
Die Standardidentität speichert ihre Aufzeichnung unter Linux und macOS in /var/lib/sxaccess/state.json. Jede andere Identität schreibt <Identität>.state.json in einen Ordner des Benutzers, der sie angelegt hat, also nach /var/lib/sxaccess/<Benutzername>/<Identität>.state.json; der Ordnername behält vom Benutzernamen nur Buchstaben, Ziffern, _ und -. SX_STATE_ROOT verschiebt /var/lib/sxaccess, und SX_DNS_STATE_PATH legt den Dateipfad direkt fest, für alle Identitäten; prüfen Sie also die Umgebung des Agenten, bevor Sie zu dem Schluss kommen, dass eine Aufzeichnung fehlt.
In jedem Fall folgt die Aufzeichnung der Identität, nicht der Organisation. Zwei Organisationen, die unter einer Identität genutzt werden, teilen sich eine Aufzeichnung, und reset --all erfasst beide.
Die Datei von Hand zu löschen ist die grobe Fassung von drop --all, mit derselben Folge: Nichts wird rückgängig gemacht. Schreibt eine dokumentierte Anleitung zum Zurücksetzen vor, die Datei zu entfernen, trennen Sie zuvor die Verbindung und setzen die Aufzeichnung zurück.
Unter macOS löscht sudo sxaccess uninstall die Aufzeichnung auf dieselbe grobe Weise, sofern Sie nicht --keep-data angeben, und sucht dabei immer in /var/lib/sxaccess, unabhängig davon, was SX_STATE_ROOT festlegt. Steht womöglich noch eine Bereinigung aus, führen Sie vor der Deinstallation sxaccess stop und sxaccess store reset --all aus.