Ping vom IPsec-Gateway nutzt eine andere Quelladresse
Ein lokal am Gateway gestarteter Ping wählt seine eigene Quelle, und diese Quelle verändert die Richtlinie und den Rückweg. Wählen Sie den Test, der belegt, was Sie brauchen.
Pingen Sie die Gegenseite vom IPsec-Gateway aus an, erhalten Sie keine Antwort und schließen daraus, der Tunnel sei defekt, während jede Arbeitslast hinter dem Gateway normal Verkehr überträgt. Die beiden Ergebnisse widersprechen sich nicht. Ein am Gateway gestarteter Ping ist ein lokal erzeugtes Paket, und das Gateway wählt eine Quelladresse aus seiner eigenen Routing-Tabelle. Diese Wahl kann von den Adressen abweichen, die der echte Standortverkehr verwendet, was ändert, welche Richtlinie greift und welcher Rückweg gilt. Entscheiden Sie, was der Test belegen soll, bevor Sie etwas in sein Ergebnis hineinlesen.
Drei verschiedene Fragen, die ein Ping beantworten kann
Die erste Frage ist, ob die Gegenseite von diesem Host überhaupt erreichbar ist. Die zweite ist, ob die Selektoren des Tunnels oder die routenbasierte Richtlinie Verkehr von einer bestimmten Quelle zulassen. Die dritte ist, ob weitergeleiteter Verkehr einer Arbeitslast hinter dem Gateway Ende zu Ende funktioniert. Ein Befehl kann nicht alle drei beantworten, und die Quelladresse ist das, was sie trennt.
Wählen Sie zuerst die Frage. Sonst wird ein fehlgeschlagener Ping zum Beleg für die Theorie, die Sie ohnehin hatten.
Warum das Gateway eine Adresse wählt, die Sie nicht erwartet haben
Wenn Sie ein Ziel anpingen, wählt der lokale Stack eine Quelle aus der Route, die dazu passt. Bei einem routenbasierten Tunnel kann das die Linkadresse der Tunnel-Schnittstelle sein, die in vielen Standortentwürfen ein 169.254.x.x-Paar ist, das für den Punkt-zu-Punkt-Hop gewählt wurde. Diese Adressen existieren, damit der Link funktioniert; sie werden auf der Gegenseite nicht als Anwendungsquellnetze angekündigt.
Die Gegenseite kann also eine Echo-Anfrage von einer Adresse erhalten, zu der sie keine Rückroute hat, oder von einer, auf die kein Selektor passt. Der Tunnel kann gesund sein und der Ping trotzdem fehlschlagen, und genau das ist das falsche Negative, um das es in diesem Artikel geht.
Wählen Sie die Quelle bewusst
Wählen Sie auf einem kontrollierten Linux-Gateway eine Quelle, die bereits lokal zugewiesen ist: ping -c 4 -I 10.30.0.1 10.40.0.20. Die Adressen hier sind beispielhaft, ersetzen Sie sie daher durch die echte innere Adresse des Gateways und ein echtes entferntes Ziel, und bestätigen Sie, dass die gewählte Quelle zu diesem Gerät gehört und von der Standortrichtlinie zugelassen wird.
Leihen Sie sich für den Test keine Adresse einer Arbeitslast. Einen Host nachzuahmen, der dem Gateway nicht zugewiesen ist, erzeugt ein Ergebnis, das niemand reproduzieren kann, und auf manchen Stacks schlägt es auf Arten fehl, die wie ein Tunneldefekt aussehen.
Lesen Sie den Rückweg, nicht nur die Anfrage
Prüfen Sie, welche Quelle tatsächlich am entfernten Ziel ankommt, einschließlich einer eventuellen bewussten Übersetzung unterwegs. Prüfen Sie dann den Rückweg der Gegenseite zu dieser Quelle und die Selektoren oder die Richtlinie, die sie zulassen. Eine Anfrage, die mit einer unerwarteten Quelle ankommt, ist eine Routing- und Richtlinienfrage, keine kryptografische.
Hier hilft auch ein Mitschnitt mehr als ein weiterer Ping: Er zeigt die Quelle, die die Gegenseite gesehen hat, und das ist die Adresse, die ihre Antwort erreichen muss.
Testen Sie dann die Arbeitslast
Der entscheidende Test ist ein Ping von einem gewöhnlichen Host hinter dem Gateway zu einem gewöhnlichen Host hinter dem entfernten Gateway. Das übt die Weiterleitungsrolle des Gateways, die echte Anwendungsquelle und den tatsächlichen Rückweg, und das ist der Fluss, der Nutzer interessiert.
Halten Sie die Ergebnisse in Ihren Notizen getrennt: Erreichbarkeit vom Gateway, Richtlinienzulassung für eine gewählte Quelle und weitergeleiteter Verkehr. Ein erfolgreicher festgelegter Ping ist ein nützlicher Beleg dafür, dass der Tunnel etwas trägt; er ist kein Beweis, dass jeder weitergeleitete Fluss funktioniert. Und eine automatisch gewählte Gateway-Quelle, die nicht erreichbar ist, ist kein Beweis dafür, dass der Standorttunnel ausgefallen ist.
Fügen Sie keine pauschale Route für 169.254.0.0/16 hinzu, nur um eine diagnostische Antwort zu bekommen. Das tauscht einen irreführenden Test gegen eine dauerhafte Routing-Entscheidung, und die nächste Person erbt sie ohne den Kontext.