Заявка към база данни засича през IPsec: пренареждане на UDP или TCP?
Заявка, която засича след чист ръкостиск, сочи навътре в пътя на тунела. Три условия решават дали да се поправи пътят, или да се мине към TCP на 443.
Заявка, която засича след TCP ръкостиск, не е проблем с маршрутизацията. Грешките в маршрута провалят ръкостиска, така че сесия, която се установи и после замлъкне, сочи навътре в пътя: инспекция, MTU или начинът, по който пристигат UDP пакетите на тунела. Решението пред вас е дали да поправите този път, или да преместите тунела на TCP. Три условия го решават и нито едно от тях не е за базата данни.
Класифицирайте засичането, преди да обвинявате тунела
Четири изхода изглеждат еднакво за потребителя и означават напълно различни неща за инженера.
| 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 |
Само последните два реда оправдават време за тунела. Отказана връзка през VPN обикновено е базата данни, която слуша само на loopback, което е проблем на слушателя, а изтичане на времето преди ръкостиска е филтър или маршрут. Нито едно от двете не се подобрява от смяна на инкапсулацията.
Запишете класификацията в тикета първо. Това е най-евтината стъпка и премахва по-голямата част от пространството за търсене.
Три условия, които решават UDP срещу TCP
Инкапсулираният трафик на IPsec върви по UDP, а UDP дава на пътя свобода да пренарежда и изпуска, без да съобщава на никого. Когато пренареждането избута пакети извън прозореца срещу повторение на тунела, те се изхвърлят тихо и вътрешната TCP сесия просто чака. Това е механизмът зад ръкостиск, който успява, и заявка, която никога не се връща.
Поправянето на пътя или минаването към TCP зависи от три неща. Първо, има ли реална загуба на пакети по пътя, или само пренареждане? Второ, можете ли да промените къде се извършва инспекцията, или да изключите този тунел от компонента, който пренарежда? Трето, чувствително ли е натоварването към модела на засичане, например много мултиплексирани сесии, споделящи една връзка?
Ако първият отговор е загуба, а вторият е не,TCP на 443 е прагматичният резервен вариант. Ако вторият отговор е да, поправете пътя и оставете UDP.
Четете записа на защитната стена, а не грешката на приложението
Приложението съобщава за изтичане на времето, което не ви казва нищо за причината. Собственият журнал на защитната стена е мястото, където се появява изхвърлянето или блокирането, затова филтрирайте по адресите на базата данни и приложението и търсете изхвърляния, както и приемания.Модулите за предотвратяване на заплахи могат да изхвърлят пакети, без да генерират грешка на ниво приложение, което е точно формата на заявка, която засича. Тишината в журнала също е данни: тя сочи към нещо, което не води журнал, като пренареждане.
Проверете и клъстера. Неправилно конфигуриран клъстер може да държи сесия в таблицата на състоянията на един член, докато пакетите минават по пътя на друг член, така че отговорите пристигат там, където няма състояние. Такива засичания изглеждат случайни и не корелират с натоварването.
Сравнете двата края, преди да промените нещо, и сравнявайте реда на пристигане, а не броя на пакетите:
tcpdump -ni any udp port 4500 -w /tmp/encap.pcap
tcpdump -ni any tcp port 5432 -w /tmp/inner.pcapКакво всъщност ви струва TCP на 443
Преместването на тунела към TCP премахва симптома на пренареждане, защото междинното устройство вече вижда подреден поток. То създава и TCP върху TCP. Външната връзка препраща това, което вътрешната вече е препратила, и една загуба може да спре всички мултиплексирани сесии наведнъж. На чист път това е невидимо. На път със загуби лечението е по-лошо от симптома.
Компромисът е приемлив, когато алтернативата е липса на свързаност, и трябва да се документира като изключение с отговорник, вместо да се приема за норма.
Запишете транспорта, порта, примерна заявка и измерения резултат, плюс датата. Без този запис следващият инженер повтаря експеримента и изключението тихо се превръща в архитектурата.
Пазете решението преразглеждаемо
Диагнозата на пътя остарява бързо. Междинното устройство се сменя, конфигурацията на модула се променя, връзката се надгражда и причината за TCP на 443 изчезва, докато конфигурацията остава. Сложете дата за преглед на изключението и назовете условието, което би ви позволило да се върнете към UDP.
Тествайте двата транспорта с малка заявка и с голям набор от резултати. Пренареждането се проявява като засичания, зависими от размера, докато повреда на слушателя спира еднакво и двата размера.