Nachvollziehen, warum eine Verbindung blockiert wird

Der Agent kann ein erfundenes Paket durch dieselben Firewall-Stufen schicken, die ein echtes durchläuft, und ausgeben, was jede Stufe entschieden hat. Führen Sie den Trace auf dem empfangenden Gerät aus, wenn zwei Geräte einander sehen und eine Verbindung zwischen ihnen trotzdem scheitert.

sxaccess info -d beantwortet, ob zwei Geräte einander sehen. Der Befehl beantwortet nicht, warum eine Verbindung zwischen ihnen abgewiesen wird - diese Entscheidung trifft der Agent auf dem empfangenden Gerät, Paket für Paket, und sie hinterlässt nichts, was sich hinterher nachlesen ließe.

sxaccess diagnose trace schließt diese Lücke. Sie beschreiben ein Paket, der Agent schickt es durch die Stufen, die ein echtes Paket durchläuft, und jede Stufe gibt ihre Entscheidung aus. Über das Netzwerk wird dabei nichts gesendet: Das Paket existiert nur im Agenten. Einen Port zu prüfen, auf dem nichts lauscht, ist deshalb unbedenklich und sagt etwas über die Regeln aus, nicht über den Dienst.

Zugriffsregeln werden dort geprüft, wo ein Paket ankommt. Führen Sie den Trace deshalb auf dem Gerät aus, das Sie erreichen wollen, als in-Trace von der Adresse des anderen Geräts. Ein out-Trace zieht die Zugriffsregeln nie heran: Er endet mit Outbound packet, allowed, unabhängig davon, was sie festlegen.

Finden, wo das Paket verworfen wird

1
Zu dem Gerät gehen, das die Verbindung abweist
Öffnen Sie eine Shell auf dem Gerät, das Sie erreichen wollen - dem Datenbankserver, nicht dem Notebook, das ihn nicht erreicht - und prüfen Sie, ob sein Agent verbunden ist. Ein Trace braucht einen verbundenen Agenten. Er funktioniert weder auf einem Linux-Gerät, bei dem sxaccess info -d in der Zeile Interface den Wert Kernel zeigt, noch auf einem Gerät, das mit --disable-firewall gestartet wurde; siehe Einschränkungen.
shell
```
sxaccess info
```
2
Die Quelladresse ermitteln
Ein Trace verwendet Overlay-Adressen, keine Namen. Das Ziel ist dieses Gerät, Sie können also self schreiben. Die Quelle ist die Adresse des Geräts, das keine Verbindung herstellen kann: Führen Sie den Befehl unten auf jenem Gerät aus; er gibt nur die Adresse aus. Führt dieses Gerät das andere auf, können Sie auch hier bleiben: sxaccess info -d --filter-by-names laptop zeigt die Adresse in der Zeile Address:.
shell
```
sxaccess info --ipv4
```
3
Das erste Paket nachstellen
Beschreiben Sie das Paket, das das andere Gerät senden würde. in ist ein Paket, das hier ankommt, gefolgt von der Quelladresse und self. --dport ist der Port des Dienstes, und --syn kennzeichnet das erste Paket einer TCP-Verbindung statt eines Teils einer bereits laufenden.
shell
```
sxaccess diagnose trace in 100.72.0.31 self -p tcp --dport 5432 --syn
```
4
Zuerst die letzte Zeile lesen
Result: ist die Antwort, ALLOWED oder DENIED. Darüber stehen die Stufen, die das Paket durchlaufen hat, in ihrer Reihenfolge, jede mit ihrer Entscheidung. Die letzte Stufe vor Completed hat den Ausschlag gegeben, und sie sagt Ihnen, was zu ändern ist.

Argumente und Optionen

Der Befehl lautet sxaccess diagnose trace <in|out> <from> <to>. Die drei Argumente sind Pflicht und stehen in dieser Reihenfolge; alles danach ist eine Option.

Argument oder Option	Bedeutung
`in`, `out`	`in` für ein Paket, das an diesem Gerät ankommt, `out` für eines, das es verlässt. Nur `in` wird gegen die Zugriffsregeln geprüft. Jedes andere Wort wird abgewiesen
`<from>`	Die IPv4-Adresse, von der das Paket kommt. `self` steht für dieses Gerät
`<to>`	Die IPv4-Adresse, an die es gerichtet ist. `self` steht für dieses Gerät
`-p`, `--protocol`	`tcp`, `udp` oder `icmp`. Standard ist `tcp`. `icmp` ist das Protokoll von ping; Ports gelten dafür nicht
`--sport`, `--dport`	Quell- und Zielport, für TCP und UDP. Für jeden, den Sie weglassen, wird ein zufälliger Port von 49152 bis 65534 gewählt
`--syn --ack --fin --rst --psh --urg`	TCP-Flags, die im Paket gesetzt werden

Die Ausgabe lesen

Die erste Zeile wiederholt das Paket so, wie Sie es eingegeben haben, damit Sie prüfen können, ob Sie das richtige Paket beschrieben haben. Danach folgt eine Zeile je Stufe, dann das Ergebnis. Im folgenden Beispiel wird eine Verbindung zu einer Datenbank, die keine Zugriffsregel erlaubt, auf dem Datenbankserver nachvollzogen:

shell - eine abgewiesene Verbindung

$ sxaccess diagnose trace in 100.72.0.31 self -p tcp --dport 5432 --synTracing TCP 100.72.0.31:52134 to self:5432Received: Got TCP packet 100.72.0.31:52134 -> 100.72.0.7:5432Connection Tracking: Not part of a tracked flowRouting: Addressed to this hostDevice ACL: Denied by device ACL (<no id>)Completed: Dropped: denied by ACLResult: DENIED

Die Stufen

Ein Paket durchläuft nicht alle Stufen. Eines, das an dieses Gerät gerichtet ist, trifft auf Routing und dann auf Device ACL; eines für ein Netz hinter diesem Gerät auf Routing, Route ACL und Forwarding. Welche Stufen auftauchen, zeigt, wie weit es gekommen ist, und das genügt meist, um die Ursache zu benennen, ohne ein Log zu lesen.

Stufe	Worüber sie entscheidet
`Received`	Das Paket so, wie der Agent es gelesen hat, mit der Adresse dieses Geräts anstelle von `self`. Falsche Adressen oder Ports sehen Sie hier
`Connection Tracking`	Ob das Paket zu einer Verbindung gehört, die dieses Gerät geöffnet hat. Ist das der Fall, wird es hier erlaubt, und der Trace endet. Deshalb brauchen Antworten keine eigene Zugriffsregel
`Routing`	Ob das Paket an dieses Gerät gerichtet ist oder in ein Netz dahinter weitergeroutet würde. `Routing is off` heißt, dass dieses Gerät für niemanden routet
`Device ACL`	Bei einem Paket an dieses Gerät: ob eine Zugriffsregel der Quelle erlaubt, es mit diesem Protokoll und Port zu erreichen. In Klammern steht die ID der passenden Zugriffsregel oder `<no id>`, wenn keine passte
`Route ACL`	Bei einem gerouteten Paket: ob eine Zugriffsregel der Quelle erlaubt, diese Adresse zu erreichen. Übernimmt das Betriebssystem das Routing, meldet die Stufe `The kernel routes this packet, route ACLs are not checked here`
`Forwarding`	Wohin ein erlaubtes geroutetes Paket weitergereicht würde
`Completed`	Das Ergebnis mit seinem Grund, etwa `Dropped: denied by ACL`. Ein `out`-Trace springt direkt hierher und meldet normalerweise `Outbound packet, allowed`

Wenn das Ergebnis DENIED lautet

Endet das Paket bei Device ACL mit <no id>, erlaubt keine Zugriffsregel der Quelle, dieses Gerät mit diesem Protokoll und Port zu erreichen. Nichts kommt durch, bis eine Regel es erlaubt - prüfen Sie also die Gruppen beider Geräte sowie Protokoll und Ports der Regel. Sollte eine Regel passen, prüfen Sie ihre Geräteanforderungen: Ein Quellgerät, das sie nicht erfüllt, fällt aus der Regel heraus, und der Trace sieht dann genauso aus, als gäbe es keine Regel.

Endet es bei Routing mit Routing is off, ist die Adresse nicht die dieses Geräts, und dieses Gerät routet für niemanden. Führen Sie den Trace stattdessen auf dem Routing-Gerät des betreffenden Netzes aus. Endet es bei Route ACL, routet dieses Gerät zwar, aber keine Regel erlaubt der Quelle, diese Adresse über dieses Gerät zu erreichen; siehe Netzwerke und Ressourcen und Private Netze routen.

Meldet der Trace ALLOWED und die Verbindung scheitert weiterhin, liegt es nicht an den Regeln. Prüfen Sie, ob auf dem Port etwas lauscht und ob die eigene Firewall des Geräts die Verbindung hereinlässt, und gehen Sie dann weiter zur Fehlerbehebung am Client.

Einschränkungen

Nur mit verbundenem Agenten. Ohne ihn scheitert der Befehl mit the agent is not connected yet.
Nur IPv4. Beide Adressen müssen IPv4-Adressen oder self sein.
Nicht, wo die System-Firewall die Regeln durchsetzt. Auf einem Linux-Gerät, bei dem sxaccess info -d in der Zeile Interface den Wert Kernel zeigt, wendet die Firewall des Betriebssystems die Zugriffsregeln an, nicht der Agent. Der Trace scheitert dann mit this device's firewall layer cannot trace packets. Diese Zeile gibt nur die Detailansicht aus.
Nicht ohne Paketfilter. Auf einem Gerät, auf dem sxaccess start mit --disable-firewall lief, lädt der Agent keinen Paketfilter; es gibt also nichts nachzuvollziehen. Der Befehl scheitert mit the agent has no firewall layer running.
Ein out-Trace verändert den Zustand. Er läuft durch den echten Ausgangsfilter und erfasst deshalb eine Verbindung, wie es ein echtes Paket täte. Ein späterer in-Trace der Antwort passt dann zu dieser Verbindung und wird bei Connection Tracking erlaubt.