Dotaz na databázi visí přes IPsec: přeskupení UDP, nebo TCP?

Dotaz, který visí po TCP handshake, není problém směrování. Chyby trasy pokazí handshake, takže relace, která se naváže a pak ztichne, ukazuje dovnitř cesty: inspekce, MTU, nebo způsob, jakým dorazí UDP pakety tunelu. Rozhodnutí před vámi je, zda tuto cestu opravit, nebo tunel přesunout na TCP. Rozhodují o tom tři podmínky a žádná z nich není o databázi.

Zařaďte zaseknutí, než obviníte tunel

Čtyři výsledky vypadají pro uživatele stejně a pro inženýra znamenají úplně jiné věci.

Čas na tunelu ospravedlňují jen poslední dva řádky. Odmítnuté připojení přes VPN bývá databáze, která poslouchá jen na loopback, což je problém posluchače, a časový limit před handshake je filtr nebo trasa. Ani jedno se nezlepší změnou zapouzdření.

Zapište klasifikaci nejdřív do tiketu. Je to nejlevnější krok a odstraní většinu prostoru hledání.

Tři podmínky, které rozhodují mezi UDP a TCP

Zapouzdřený provoz IPsec jezdí přes UDP a UDP dává cestě volnost přeskupovat a zahazovat, aniž by to komukoli řekla. Když přeskupení vytlačí pakety mimo okno proti opakování tunelu, jsou tiše zahozeny a vnitřní TCP relace prostě čeká. To je mechanismus za handshake, který uspěje, a dotazem, který se nikdy nevrátí.

Oprava cesty nebo návrat k TCP závisí na třech věcech. Za prvé, je na cestě skutečná ztráta paketů, nebo jen přeskupení? Za druhé, můžete změnit, kde inspekce probíhá, nebo tento tunel vyloučit z komponenty, která přeskupuje? Za třetí, je zátěž citlivá na vzorec zaseknutí, například mnoho multiplexovaných relací sdílejících jedno spojení?

Pokud první odpověď je ztráta a druhá ne,TCP na 443 je pragmatická záloha. Pokud je druhá odpověď ano, opravte cestu a ponechte UDP.

Čtěte záznam firewallu, ne chybu aplikace

Aplikace hlásí časový limit, což o příčině nic neříká. Vlastní log firewallu je místo, kde se objeví zahození nebo blokování, takže filtrujte podle adres databáze a aplikace a hledejte zahození i přijetí.Moduly prevence hrozeb mohou zahodit pakety, aniž by vytvořily chybu na úrovni aplikace, což je přesně podoba dotazu, který visí. Ticho v logu je také data: ukazuje na něco, co neloguje, například přeskupení.

Zkontrolujte i cluster. Špatně nakonfigurovaný cluster může držet relaci v tabulce stavů na jednom členu, zatímco pakety jdou cestou jiného členu, takže odpovědi dorazí tam, kde žádný stav není. Taková zaseknutí vypadají náhodně a nekorelují se zátěží.

Porovnejte oba konce, než cokoli změníte, a porovnávejte pořadí příchodu, ne počty paketů:

tcpdump -ni any udp port 4500 -w /tmp/encap.pcap
tcpdump -ni any tcp port 5432 -w /tmp/inner.pcap

Co vás TCP na 443 skutečně stojí

Přesun tunelu na TCP odstraní příznak přeskupení, protože middlebox nyní vidí uspořádaný proud. Také vytváří TCP-over-TCP. Vnější spojení přenáší znovu to, co vnitřní už přeneslo, a jediná ztráta může naráz zastavit všechny multiplexované relace. Na čisté cestě je to neviditelné. Na cestě se ztrátami je lék horší než příznak.

Výměna je přijatelná, když je alternativou žádné připojení, a má být zdokumentována jako výjimka s vlastníkem, ne přijata jako normál.

Zapište transport, port, ukázkový dotaz a naměřený výsledek plus datum. Bez toho záznamu další inženýr opakuje experiment a výjimka se tiše stane architekturou.

Udržte rozhodnutí revidovatelné

Diagnóza cesty rychle stárne. Middlebox se vymění, konfigurace modulu se změní, spojení se vylepší a důvod pro TCP na 443 zmizí, zatímco konfigurace zůstane. Dejte výjimce datum revize a pojmenujte podmínku, která by vám umožnila vrátit se k UDP.

Otestujte oba transporty malým dotazem a velkou sadou výsledků. Přeskupení se projeví jako zaseknutí závislá na velikosti, zatímco porucha posluchače zastaví obě velikosti stejně.