Una query al database si blocca su IPsec: riordino UDP o TCP?
Una query che si blocca dopo un handshake pulito indica l'interno del percorso del tunnel. Tre condizioni decidono se riparare il percorso o tornare a TCP sulla 443.
Una query che si blocca dopo l'handshake TCP non è un problema di routing. I guasti di rotta fanno fallire l'handshake, quindi una sessione che si stabilisce e poi tace indica l'interno del percorso: ispezione, MTU o il modo in cui arrivano i pacchetti UDP del tunnel. La decisione davanti a voi è se riparare quel percorso o spostare il tunnel su TCP. Tre condizioni la risolvono, e nessuna riguarda il database.
Classificate lo stallo prima di dare la colpa al tunnel
Quattro esiti sembrano uguali a un utente e significano cose del tutto diverse per un ingegnere.
| 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 |
Solo le ultime due righe giustificano tempo sul tunnel. Una connessione rifiutata attraverso una VPN è di solito il database in ascolto solo su loopback, che è un problema di listener, e un timeout prima dell'handshake è un filtro o una rotta. Nessuno dei due migliora cambiando l'incapsulamento.
Scrivete la classificazione nel ticket per primo. È il passo più economico e rimuove la maggior parte dello spazio di ricerca.
Tre condizioni che decidono tra UDP e TCP
Il traffico IPsec incapsulato viaggia su UDP, e UDP lascia al percorso la libertà di riordinare e scartare senza dirlo a nessuno. Quando il riordino spinge i pacchetti fuori dalla finestra anti-replay del tunnel, vengono scartati in silenzio e la sessione TCP interna aspetta e basta. È il meccanismo dietro un handshake che riesce e una query che non torna mai.
Riparare il percorso o tornare a TCP dipende da tre cose. Primo, c'è una vera perdita di pacchetti sul percorso, o solo riordino? Secondo, potete cambiare dove avviene l'ispezione, o escludere questo tunnel dal componente che riordina? Terzo, il carico è sensibile al modello di stallo, per esempio molte sessioni multiplexate che condividono un solo collegamento?
Se la prima risposta è perdita e la seconda è no,TCP sulla 443 è l'alternativa pragmatica. Se la seconda risposta è sì, riparate il percorso e tenete UDP.
Leggete il registro del firewall, non l'errore dell'applicazione
L'applicazione segnala un timeout, che non dice nulla sulla causa. Il log del firewall è il punto in cui compare lo scarto o il blocco, quindi filtrate per gli indirizzi del database e dell'applicazione e cercate gli scarti oltre alle accettazioni.I moduli di prevenzione delle minacce possono scartare pacchetti senza generare un errore a livello di applicazione, ed è esattamente la forma di una query che si blocca. Il silenzio nel log è anch'esso un dato: indica qualcosa che non registra, come il riordino.
Controllate anche il cluster. Un cluster mal configurato può trattenere una sessione nella tabella degli stati su un membro mentre i pacchetti seguono il percorso di un altro membro, così le risposte arrivano dove non esiste stato. Tali stalli sembrano casuali e non correlano con il carico.
Confrontate entrambe le estremità prima di cambiare qualcosa, e confrontate l'ordine di arrivo invece del numero di pacchetti:
tcpdump -ni any udp port 4500 -w /tmp/encap.pcap
tcpdump -ni any tcp port 5432 -w /tmp/inner.pcapQuanto vi costa davvero TCP sulla 443
Spostare il tunnel su TCP elimina il sintomo del riordino, perché il middlebox ora vede un flusso ordinato. Crea anche TCP su TCP. La connessione esterna ritrasmette ciò che quella interna ha già ritrasmesso, e una sola perdita può fermare tutte le sessioni multiplexate insieme. Su un percorso pulito è invisibile. Su uno con perdite la cura è peggiore del sintomo.
Lo scambio è accettabile quando l'alternativa è nessuna connettività, e va documentato come eccezione con un responsabile invece di essere assorbito come normale.
Registrate il trasporto, la porta, una query di esempio e il risultato misurato, più la data. Senza quel registro l'ingegnere successivo ripete l'esperimento, e l'eccezione diventa silenziosamente l'architettura.
Mantenete la decisione rivedibile
Una diagnosi del percorso invecchia male. Il middlebox viene sostituito, la configurazione del modulo cambia, il collegamento viene aggiornato, e il motivo del TCP sulla 443 sparisce mentre la configurazione resta. Mettete una data di revisione sull'eccezione e nominate la condizione che vi permetterebbe di tornare a UDP.
Provate entrambi i trasporti con una query piccola e con un set di risultati grande. Il riordino si manifesta come stalli dipendenti dalla dimensione, mentre un guasto del listener ferma entrambe le dimensioni allo stesso modo.