Datenbankabfrage hängt über IPsec: UDP-Umordnung oder TCP?
Eine Abfrage, die nach einem sauberen Handshake hängt, deutet ins Innere des Tunnelpfads. Drei Bedingungen entscheiden, ob man den Pfad repariert oder auf TCP auf 443 zurückfällt.
Eine Abfrage, die nach dem TCP-Handshake hängt, ist kein Routingproblem. Routenfehler lassen den Handshake scheitern, eine Sitzung, die sich aufbaut und dann verstummt, deutet also ins Innere des Pfads: Inspektion, MTU oder die Art, wie die UDP-Pakete des Tunnels ankommen. Die Entscheidung vor Ihnen ist, ob Sie diesen Pfad reparieren oder den Tunnel auf TCP umstellen. Drei Bedingungen entscheiden das, und keine davon betrifft die Datenbank.
Klassifizieren Sie den Stillstand, bevor Sie den Tunnel beschuldigen
Vier Ergebnisse sehen für einen Nutzer gleich aus und bedeuten für einen Ingenieur völlig verschiedene Dinge.
| What the client sees | What it rules out |
|---|---|
| Connection refused | Nothing is listening on the address and port the client reached |
| Timeout before the handshake | A filter, a missing route, or the wrong address |
| Handshake completes, query hangs | The session exists, so look at inspection, MTU and packet order |
| Stalls that recover on retry | Often reordering, or a state table entry expiring |
Nur die letzten beiden Zeilen rechtfertigen Zeit am Tunnel. Eine abgelehnte Verbindung über ein VPN ist meist die Datenbank, die nur auf loopback lauscht, was ein Listener-Problem ist, und ein Timeout vor dem Handshake ist ein Filter oder eine Route. Keines davon bessert sich durch einen Wechsel der Kapselung.
Schreiben Sie die Klassifikation zuerst ins Ticket. Das ist der billigste Schritt, und er entfernt den größten Teil des Suchraums.
Drei Bedingungen, die UDP gegen TCP entscheiden
Gekapselter IPsec-Verkehr läuft über UDP, und UDP gibt dem Pfad die Freiheit, umzuordnen und zu verwerfen, ohne es jemandem zu sagen. Wenn die Umordnung Pakete außerhalb des Anti-Replay-Fensters des Tunnels schiebt, werden sie stillschweigend verworfen, und die innere TCP-Sitzung wartet einfach. Das ist der Mechanismus hinter einem Handshake, der gelingt, und einer Abfrage, die nie zurückkehrt.
Ob Sie den Pfad reparieren oder auf TCP zurückfallen, hängt an drei Dingen. Erstens: Gibt es echten Paketverlust auf dem Pfad, oder nur Umordnung? Zweitens: Können Sie ändern, wo die Inspektion stattfindet, oder diesen Tunnel von der Komponente ausnehmen, die umordnet? Drittens: Ist die Last empfindlich gegen das Stillstandsmuster, etwa viele gemultiplexte Sitzungen, die sich eine Verbindung teilen?
Ist die erste Antwort Verlust und die zweite nein,ist TCP auf 443 der pragmatische Rückfall. Ist die zweite Antwort ja, reparieren Sie den Pfad und behalten Sie UDP.
Lesen Sie den Firewall-Eintrag, nicht den Anwendungsfehler
Die Anwendung meldet ein Timeout, was über die Ursache nichts sagt. Das eigene Log der Firewall ist der Ort, an dem Verwerfen oder Blocken auftaucht, filtern Sie also nach den Adressen von Datenbank und Anwendung und suchen Sie nach Verwerfungen ebenso wie nach Annahmen.Blades zur Bedrohungsabwehr können Pakete verwerfen, ohne einen Fehler auf Anwendungsebene zu erzeugen, und genau das ist die Form einer Abfrage, die hängt. Stille im Log sind ebenfalls Daten: Sie deutet auf etwas, das nicht loggt, etwa Umordnung.
Prüfen Sie auch den Cluster. Ein falsch konfigurierter Cluster kann eine Sitzung in der Statustabelle auf einem Mitglied halten, während die Pakete den Pfad eines anderen Mitglieds nehmen, sodass Antworten dort ankommen, wo kein Status existiert. Solche Stillstände wirken zufällig und korrelieren nicht mit Last.
Vergleichen Sie beide Enden, bevor Sie etwas ändern, und vergleichen Sie die Ankunftsreihenfolge statt der Paketzahlen:
tcpdump -ni any udp port 4500 -w /tmp/encap.pcap
tcpdump -ni any tcp port 5432 -w /tmp/inner.pcapWas TCP auf 443 Sie tatsächlich kostet
Der Umzug des Tunnels auf TCP beseitigt das Umordnungssymptom, weil die Middlebox nun einen geordneten Strom sieht. Er erzeugt aber auch TCP über TCP. Die äußere Verbindung wiederholt, was die innere bereits wiederholt hat, und ein einzelner Verlust kann alle gemultiplexten Sitzungen auf einmal stoppen. Auf einem sauberen Pfad ist das unsichtbar. Auf einem verlustbehafteten ist die Kur schlimmer als das Symptom.
Der Tausch ist akzeptabel, wenn die Alternative keine Konnektivität ist, und er sollte als Ausnahme mit einem Verantwortlichen dokumentiert statt als normal hingenommen werden.
Halten Sie Transport, Port, eine Beispielabfrage und das gemessene Ergebnis samt Datum fest. Ohne diesen Eintrag wiederholt der nächste Ingenieur das Experiment, und die Ausnahme wird stillschweigend zur Architektur.
Halten Sie die Entscheidung überprüfbar
Eine Pfaddiagnose altert schlecht. Die Middlebox wird ersetzt, die Blade-Konfiguration ändert sich, der Link wird aufgerüstet, und der Grund für TCP auf 443 verschwindet, während die Konfiguration bleibt. Setzen Sie ein Überprüfungsdatum auf die Ausnahme und benennen Sie die Bedingung, die eine Rückkehr zu UDP erlauben würde.
Testen Sie beide Transporte mit einer kleinen Abfrage und mit einem großen Ergebnisssatz. Umordnung zeigt sich als größenabhängige Stillstände, während ein Listener-Fehler beide Größen gleichermaßen stoppt.