O interogare la baza de date se blochează prin IPsec: reordonare UDP sau TCP?
O interogare care se blochează după un handshake curat indică interiorul căii tunelului. Trei condiții decid dacă se repară calea sau se revine la TCP pe 443.
O interogare care se blochează după handshake-ul TCP nu este o problemă de rutare. Erorile de rută fac handshake-ul să eșueze, așa că o sesiune care se stabilește și apoi tace indică interiorul căii: inspecție, MTU sau felul în care sosesc pachetele UDP ale tunelului. Decizia din fața dumneavoastră este dacă reparați acea cale sau mutați tunelul pe TCP. Trei condiții o decid, și niciuna nu este despre baza de date.
Clasificați blocajul înainte de a da vina pe tunel
Patru rezultate arată la fel pentru un utilizator și înseamnă lucruri complet diferite pentru un inginer.
| 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 |
Doar ultimele două rânduri justifică timp pe tunel. O conexiune refuzată printr-un VPN este de obicei baza de date care ascultă doar pe loopback, ceea ce este o problemă de ascultare, iar un timeout înainte de handshake este un filtru sau o rută. Niciuna nu se îmbunătățește schimbând encapsularea.
Scrieți clasificarea în tichet mai întâi. Este cel mai ieftin pas și elimină cea mai mare parte a spațiului de căutare.
Trei condiții care decid între UDP și TCP
Traficul IPsec encapsulat merge pe UDP, iar UDP dă căii libertatea de a reordona și de a arunca fără să spună nimănui. Când reordonarea împinge pachetele în afara ferestrei anti-repetiție a tunelului, acestea sunt aruncate în tăcere, iar sesiunea TCP interioară pur și simplu așteaptă. Acesta este mecanismul din spatele unui handshake care reușește și al unei interogări care nu se întoarce niciodată.
Repararea căii sau revenirea la TCP depinde de trei lucruri. În primul rând, există pierdere reală de pachete pe cale, sau doar reordonare? În al doilea rând, puteți schimba locul unde are loc inspecția, sau exclude acest tunel din componenta care reordonează? În al treilea rând, este sarcina sensibilă la tiparul blocajelor, de exemplu multe sesiuni multiplexate care partajează o singură legătură?
Dacă primul răspuns este pierdere, iar al doilea este nu,TCP pe 443 este alternativa pragmatică. Dacă al doilea răspuns este da, reparați calea și păstrați UDP.
Citiți înregistrarea firewall-ului, nu eroarea aplicației
Aplicația raportează un timeout, care nu spune nimic despre cauză. Jurnalul propriu al firewall-ului este locul unde apare aruncarea sau blocarea, așa că filtrați după adresele bazei de date și ale aplicației și căutați aruncări, precum și acceptări.Modulele de prevenire a amenințărilor pot arunca pachete fără a genera o eroare la nivel de aplicație, iar aceasta este exact forma unei interogări care se blochează. Tăcerea din jurnal este și ea un dat: indică ceva ce nu înregistrează, cum ar fi reordonarea.
Verificați și clusterul. Un cluster configurat greșit poate ține o sesiune în tabela de stări pe un membru în timp ce pachetele urmează calea altui membru, așa că răspunsurile ajung unde nu există stare. Astfel de blocaje par aleatorii și nu se corelează cu încărcarea.
Comparați ambele capete înainte de a schimba ceva și comparați ordinea de sosire, nu numărul de pachete:
tcpdump -ni any udp port 4500 -w /tmp/encap.pcap
tcpdump -ni any tcp port 5432 -w /tmp/inner.pcapCât vă costă de fapt TCP pe 443
Mutarea tunelului pe TCP elimină simptomul reordonării, pentru că middlebox-ul vede acum un flux ordonat. Creează însă și TCP peste TCP. Conexiunea exterioară retransmite ceea ce cea interioară a retransmis deja, iar o singură pierdere poate opri toate sesiunile multiplexate deodată. Pe o cale curată acest lucru este invizibil. Pe una cu pierderi, remediul este mai rău decât simptomul.
Schimbul este acceptabil atunci când alternativa este lipsa conectivității, și ar trebui documentat ca excepție cu un responsabil, în loc să fie absorbit ca normalitate.
Înregistrați transportul, portul, o interogare exemplu și rezultatul măsurat, plus data. Fără acea înregistrare, următorul inginer repetă experimentul, iar excepția devine în tăcere arhitectura.
Păstrați decizia reexaminabilă
O diagnoză de cale îmbătrânește repede. Middlebox-ul este înlocuit, configurația modulului se schimbă, legătura este modernizată, iar motivul pentru TCP pe 443 dispare în timp ce configurația rămâne. Puneți o dată de revizuire pe excepție și numiți condiția care v-ar permite să reveniți la UDP.
Testați ambele transporturi cu o interogare mică și cu un set mare de rezultate. Reordonarea se manifestă ca blocaje dependente de dimensiune, în timp ce o defecțiune de ascultare oprește ambele dimensiuni la fel.