Adatbázis-lekérdezés akad meg IPsec felett: UDP-átrendezés vagy TCP?
A tiszta kézfogás után megakadó lekérdezés az alagút útvonalának belsejére mutat. Három feltétel dönti el, hogy javítani kell-e az útvonalat, vagy vissza kell térni a TCP-re a 443-as porton.
A TCP kézfogás után megakadó lekérdezés nem útvonalválasztási probléma. Az útvonalhibák a kézfogást buktatják el, tehát a létrejövő, majd elhallgató munkamenet az útvonal belsejére mutat: vizsgálat, MTU, vagy ahogy az alagút UDP-csomagjai megérkeznek. Az előtted álló döntés, hogy ezt az útvonalat javítsd-e, vagy az alagutat TCP-re állítsd. Három feltétel dönti el, és egyik sem az adatbázisról szól.
Osztályozd az akadást, mielőtt az alagutat hibáztatnád
Négy kimenet hasonlónak tűnik a felhasználónak, és teljesen mást jelent a mérnöknek.
| 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 |
Csak az utolsó két sor jogosítja fel az alagútra szánt időt. A VPN-en át elutasított kapcsolat általában az, hogy az adatbázis csak loopbacken figyel, ami hallgató-probléma, a kézfogás előtti időtúllépés pedig szűrő vagy útvonal. Egyik sem javul a csomagolás megváltoztatásától.
Először írd be az osztályozást a ticketbe. Ez a legolcsóbb lépés, és a keresési tér nagy részét eltávolítja.
Három feltétel, amely eldönti az UDP és a TCP között
A becsomagolt IPsec-forgalom UDP-n utazik, az UDP pedig szabadságot ad az útvonalnak az átrendezésre és az eldobásra anélkül, hogy bárkinek szólna. Amikor az átrendezés kiszorítja a csomagokat az alagút ismétlés elleni ablakán kívülre, azokat csendben eldobják, és a belső TCP-munkamenet egyszerűen vár. Ez a mechanizmus a sikeres kézfogás és a soha vissza nem térő lekérdezés mögött.
Az útvonal javítása vagy a TCP-re való visszatérés három dologtól függ. Először, van-e valódi csomagvesztés az útvonalon, vagy csak átrendezés? Másodszor, meg tudod-e változtatni, hol történik a vizsgálat, vagy ki tudod-e zárni ezt az alagutat az átrendező komponensből? Harmadszor, érzékeny-e a terhelés az akadási mintára, például sok multiplexelt munkamenet egyetlen kapcsolaton?
Ha az első válasz veszteség, a második pedig nem,a 443-as TCP a pragmatikus visszaesés. Ha a második válasz igen, javítsd az útvonalat, és tartsd meg az UDP-t.
A tűzfal feljegyzését olvasd, ne az alkalmazás hibáját
Az alkalmazás időtúllépést jelent, ami semmit nem mond az okról. A tűzfal saját naplója az a hely, ahol az eldobás vagy a blokkolás megjelenik, ezért szűrj az adatbázis és az alkalmazás címére, és keress eldobásokat éppúgy, mint elfogadásokat.A fenyegetés-megelőzési modulok eldobhatnak csomagokat anélkül, hogy alkalmazásszintű hibát generálnának, és pontosan ez a megakadó lekérdezés alakja. A napló csendje is adat: olyasmire mutat, ami nem naplóz, például az átrendezésre.
Ellenőrizd a klasztert is. Egy rosszul beállított klaszter az egyik tag állapottáblájában tarthat egy munkamenetet, miközben a csomagok egy másik tag útvonalán mennek, így a válaszok olyan helyre érkeznek, ahol nincs állapot. Az ilyen akadások véletlenszerűnek tűnnek, és nem korrelálnak a terheléssel.
Hasonlítsd össze mindkét véget, mielőtt bármit változtatnál, és a csomagszám helyett az érkezési sorrendet hasonlítsd össze:
tcpdump -ni any udp port 4500 -w /tmp/encap.pcap
tcpdump -ni any tcp port 5432 -w /tmp/inner.pcapMennyibe kerül neked valójában a 443-as TCP
Az alagút TCP-re állítása megszünteti az átrendezés tünetét, mert a köztes eszköz most rendezett adatfolyamot lát. Ugyanakkor TCP-over-TCP-t hoz létre. A külső kapcsolat újraküldi azt, amit a belső már újraküldött, és egyetlen veszteség egyszerre akaszthatja meg az összes multiplexelt munkamenetet. Tiszta útvonalon ez láthatatlan. Veszteséges útvonalon a gyógymód rosszabb a tünetnél.
A csere akkor elfogadható, ha az alternatíva a kapcsolat teljes hiánya, és tulajdonossal rendelkező kivételként kell dokumentálni, nem normálként elfogadni.
Jegyezd fel a transzportot, a portot, egy mintalekérdezést és a mért eredményt, valamint a dátumot. E feljegyzés nélkül a következő mérnök megismétli a kísérletet, és a kivétel csendben az architektúrává válik.
Tartsd felülvizsgálhatónak a döntést
Az útvonal-diagnózis gyorsan elavul. A köztes eszközt kicserélik, a modul konfigurációja változik, a kapcsolatot fejlesztik, és a 443-as TCP oka eltűnik, miközben a konfiguráció megmarad. Tegyél felülvizsgálati dátumot a kivételre, és nevezd meg a feltételt, amely lehetővé tenné a visszatérést az UDP-hez.
Teszteld mindkét transzportot kis lekérdezéssel és nagy eredményhalmazzal. Az átrendezés mérettől függő akadásként jelenik meg, míg a hallgatóhiba mindkét méretet egyformán megállítja.