Ping ist kein Beweis: den Pfad zwischen zwei Standorten testen

Ein Ping vom Gateway sagt nichts über den Dienst aus. Gehen Sie den Pfad von einem echten Client, nutzen Sie das Protokoll der Anwendung und reproduzieren Sie die Größe oder den Namen, der scheitert.

Der Tunnel steht, die Gateways antworten einander, und die Nutzer am einen Standort können die Dateifreigabe am anderen noch immer nicht öffnen. Jemand pingt vom Gateway, bekommt eine Antwort und erklärt das Netz für gesund. Diese Antwort reiste zwischen zwei Geräten, die nie das Problem waren. Ein nützlicher Test beginnt am Host, der den Dienst braucht, nutzt das Protokoll, das die Anwendung nutzt, und reproduziert die Bedingung, unter der er scheitert. Alles andere ist grünes Licht für einen Pfad, auf dem niemand unterwegs ist.

Beginnen Sie beim Client, der den Dienst braucht

Notieren Sie vier Dinge, bevor Sie irgendetwas testen: die Client-Adresse, die Zieladresse, den Hostnamen und den Port der Anwendung. Bestätigen Sie dann, dass der Dienst lokal am eigenen Standort funktioniert, von einem Host daneben aus. Ohne diese Basislinie können Sie einen defekten Tunnel nicht von einem defekten Dienst unterscheiden, und die Hälfte dieser Tickets ist der zweite Fall.

Probieren Sie den dokumentierten Hostnamen und, wo der Dienst es zulässt, eine Prüfung der direkten Adresse desselben Ports. Eine fehlgeschlagene Namensauflösung und eine nicht erreichbare aufgelöste Adresse führen Sie auf verschiedene Wege. Wenn Sie einen Hostnamen durch eine IP ersetzen, deaktivieren Sie nicht die HTTPS-Identitätsprüfung, damit es funktioniert; eine Zertifikatswarnung ist Information, kein Hindernis.

Gehen Sie den Pfad an jeder Kante

Lesen Sie die Route, die der Client wählt, dann die Route, die das Gateway für dieses Ziel wählt, dann die Zähler oder einen begrenzten Mitschnitt an jeder Kante. Sie suchen zwei Fakten: Kam die Anfrage im entfernten LAN an, und kam eine Antwort zurück. Interface-Zähler enthalten jeden anderen Fluss, also korrelieren Sie nach exaktem Zeitstempel und Adresspaar statt nach der Form des Diagramms. Ein Mitschnitt an der falschen Kante ist schlimmer als keiner, weil er wie ein Beweis aussieht.

ip route get 10.10.0.5
sudo tcpdump -ni any host 10.10.0.5 and port 445
sudo tcpdump -ni any net 10.10.0.0/24 and net 10.20.0.0/24

Wenn die Anfrage an der entfernten Kante auftaucht, ohne dass eine Antwort dahinter steht, liegt das Problem auf der anderen Seite: eine Firewall, eine fehlende Rückroute oder ein Host, der die Quelle nicht akzeptiert. Wenn die Anfrage nie auftaucht, haben die lokale Route oder die Tunnel-Selektoren sie nicht getragen, und die andere Seite ist noch keine Untersuchung wert.

Nutzen Sie das Protokoll, das die Anwendung nutzt

ICMP ist eine schwache Sonde. Es kann gefiltert, ratenbegrenzt oder von einer anderen Richtlinie als der Dienst behandelt werden, was sowohl seinen Erfolg als auch sein Scheitern mehrdeutig macht. Testen Sie den tatsächlichen Port und, wo möglich, den tatsächlichen Protokoll-Handshake.

nc -vz 10.10.0.5 445
curl -sv --max-time 5 https://files.corp.internal/ -o /dev/null
openssl s_client -connect 10.10.0.5:443 -servername files.corp.internal

Ein abgeschlossener TCP-Handshake beweist Erreichbarkeit und Richtlinie für diesen Port. Er beweist nicht, dass die Anwendung funktioniert: Authentifizierung, ein Upload oder ein bestimmter API-Aufruf können weiterhin scheitern. Testen Sie den Vorgang, den Nutzer tatsächlich ausführen, mit einem harmlosen Äquivalent, statt wiederholt eine echte Transaktion einzureichen.

Reproduzieren Sie die Bedingung, die scheitert

Fehler, die nur bei großen Übertragungen auftreten, sind ein Größenproblem, kein Konnektivitätsproblem. Senden Sie ein großes Paket mit gesetztem don't-fragment-Bit und beobachten Sie, wo es stoppt. Wenn eine kleine Anfrage gelingt und eine große hängt, sind die Tunnel-MTU und die MSS-Behandlung an den Gateways die nächsten Verdächtigen.

ping -M do -s 1400 10.10.0.5
ping -M do -s 1472 10.10.0.5
curl -sS --max-time 30 -F file=@./sample.bin https://files.corp.internal/upload

Wenn nur ein Subnetz scheitert, prüfen Sie Traffic-Selektoren, Routenankündigungen und das Rück-Gateway dieses Subnetzes. Wenn nur der Hostname scheitert, folgen Sie DNS, einschließlich welchen Resolver der Client nutzte und ob die entfernte Ansicht von diesem Standort aus sichtbar ist. Drei verschiedene Fehler, drei verschiedene Korrekturen, und der Ping-Test unterscheidet keinen davon.

Wiederholen Sie nach der Korrektur denselben Test

Starten Sie denselben Client, dasselbe Ziel, denselben Port und dieselbe Nutzlast erneut. Verbinden Sie dann neu oder üben Sie den Failover-Pfad, falls das Design einen hat, denn eine Korrektur, die nur funktioniert, solange die ursprüngliche Tunnelinstanz lebt, ist nicht getestet. Halten Sie den Test an eine echte Quelle, ein echtes Ziel und einen echten Vorgang gebunden statt an eine grüne Anzeige auf einem Dashboard.

Halten Sie die vier Basiswerte und das Ergebnis fest. Der nächste Bericht über dasselbe Symptom kann dann mit Beweisen beginnen statt mit einem Ping.

Ähnliche Artikel