Databasequery blijft hangen over IPsec: UDP-herschikking of TCP?
Een query die na een schone handshake blijft hangen, wijst naar de binnenkant van het tunnelpad. Drie voorwaarden bepalen of je het pad repareert of terugvalt op TCP op 443.
Een query die na de TCP-handshake blijft hangen, is geen routeringsprobleem. Routfouten laten de handshake mislukken, dus een sessie die tot stand komt en daarna stilvalt, wijst naar de binnenkant van het pad: inspectie, MTU of de manier waarop de UDP-pakketten van de tunnel aankomen. De beslissing voor u is of u dat pad repareert of de tunnel naar TCP verplaatst. Drie voorwaarden beslechten het, en geen ervan gaat over de database.
Classificeer de stilstand voordat u de tunnel de schuld geeft
Vier uitkomsten lijken voor een gebruiker hetzelfde en betekenen voor een ingenieur heel verschillende dingen.
| 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 |
Alleen de laatste twee rijen rechtvaardigen tijd aan de tunnel. Een geweigerde verbinding over een VPN is meestal de database die alleen op loopback luistert, wat een luisteraarprobleem is, en een time-out vóór de handshake is een filter of een route. Geen van beide verbetert door de inkapseling te wijzigen.
Schrijf de classificatie eerst in de ticket. Het is de goedkoopste stap en verwijdert het grootste deel van de zoekruimte.
Drie voorwaarden die UDP tegen TCP beslechten
Ingekapseld IPsec-verkeer rijdt op UDP, en UDP geeft het pad de vrijheid om te herschikken en te laten vallen zonder het iemand te vertellen. Wanneer herschikking pakketten buiten het anti-replayvenster van de tunnel duwt, worden ze stil weggegooid en de binnenste TCP-sessie wacht gewoon. Dat is het mechanisme achter een handshake die slaagt en een query die nooit terugkomt.
Het pad repareren of terugvallen op TCP hangt van drie dingen af. Ten eerste, is er echt pakketverlies op het pad, of alleen herschikking? Ten tweede, kunt u wijzigen waar de inspectie plaatsvindt, of deze tunnel uitsluiten van de component die herschikt? Ten derde, is de werklast gevoelig voor het stollingspatroon, bijvoorbeeld veel gemultiplexte sessies die één link delen?
Als het eerste antwoord verlies is en het tweede nee,is TCP op 443 de pragmatische terugval. Als het tweede antwoord ja is, repareer het pad en houd UDP.
Lees het firewallrecord, niet de fout van de toepassing
De toepassing meldt een time-out, wat niets over de oorzaak zegt. Het eigen log van de firewall is de plek waar het weggooien of blokkeren verschijnt, dus filter op de adressen van de database en de toepassing en zoek naar weggooiingen én acceptaties.Blades voor dreigingspreventie kunnen pakketten weggooien zonder een fout op toepassingsniveau te veroorzaken, en dat is precies de vorm van een query die blijft hangen. Stilte in het log is ook data: het wijst naar iets dat niet logt, zoals herschikking.
Controleer ook het cluster. Een verkeerd geconfigureerd cluster kan een sessie in de statustabel op het ene lid houden terwijl de pakketten het pad van een ander lid nemen, zodat antwoorden aankomen waar geen status bestaat. Zulke stiltes lijken willekeurig en correleren niet met belasting.
Vergelijk beide uiteinden voordat u iets wijzigt, en vergelijk de aankomstvolgorde in plaats van de pakketaantallen:
tcpdump -ni any udp port 4500 -w /tmp/encap.pcap
tcpdump -ni any tcp port 5432 -w /tmp/inner.pcapWat TCP op 443 u werkelijk kost
De tunnel naar TCP verplaatsen verwijdert het herschikkingssymptoom, omdat de middlebox nu een geordende stroom ziet. Het creëert ook TCP over TCP. De buitenste verbinding verzendt opnieuw wat de binnenste al opnieuw heeft verzonden, en één verlies kan alle gemultiplexte sessies tegelijk stilzetten. Op een schoon pad is dat onzichtbaar. Op een pad met verlies is de kuur erger dan het symptoom.
De ruil is aanvaardbaar wanneer het alternatief geen connectiviteit is, en moet worden gedocumenteerd als uitzondering met een eigenaar in plaats van als normaal te worden geabsorbeerd.
Leg het transport, de poort, een voorbeeldquery en het gemeten resultaat vast, plus de datum. Zonder dat record herhaalt de volgende ingenieur het experiment, en de uitzondering wordt stil de architectuur.
Houd de beslissing herzienbaar
Een paddiagnose veroudert snel. De middlebox wordt vervangen, de blade-configuratie verandert, de link wordt opgewaardeerd, en de reden voor TCP op 443 verdwijnt terwijl de configuratie blijft. Zet een herzieningsdatum op de uitzondering en benoem de voorwaarde die u naar UDP zou laten terugkeren.
Test beide transporten met een kleine query en met een grote resultatenset. Herschikking uit zich als grootteafhankelijke stiltes, terwijl een luisteraarfout beide groottes gelijk stopt.