Zapytanie do bazy danych zawiesza się przez IPsec: przemieszanie UDP czy TCP?
Zapytanie, które zawiesza się po czystym handshake, wskazuje wnętrze ścieżki tunelu. Trzy warunki decydują, czy naprawić ścieżkę, czy wrócić do TCP na 443.
Zapytanie, które zawiesza się po handshake TCP, nie jest problemem routingu. Błędy trasy psują handshake, więc sesja, która się nawiązuje i potem milknie, wskazuje wnętrze ścieżki: inspekcję, MTU albo sposób, w jaki docierają pakiety UDP tunelu. Decyzja przed tobą to naprawić tę ścieżkę czy przenieść tunel na TCP. Trzy warunki to rozstrzygają, i żaden nie dotyczy bazy danych.
Sklasyfikuj zawieszenie, zanim obwinisz tunel
Cztery wyniki wyglądają dla użytkownika tak samo, a dla inżyniera znaczą zupełnie coś innego.
| 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 |
Tylko dwa ostatnie wiersze uzasadniają czas na tunelu. Odrzucone połączenie przez VPN to zwykle baza danych nasłuchująca tylko na loopback, co jest problemem nasłuchu, a przekroczenie czasu przed handshake to filtr albo trasa. Żadne z nich nie poprawia się przez zmianę enkapsulacji.
Najpierw zapisz klasyfikację w zgłoszeniu. To najtańszy krok i usuwa większość przestrzeni poszukiwań.
Trzy warunki, które rozstrzygają między UDP a TCP
Enkapsulowany ruch IPsec jedzie po UDP, a UDP daje ścieżce swobodę przestawiania i gubienia bez informowania nikogo. Gdy przestawianie wypycha pakiety poza okno przeciw powtórzeniom tunelu, są po cichu odrzucane, a wewnętrzna sesja TCP po prostu czeka. To mechanizm za udanym handshake i zapytaniem, które nigdy nie wraca.
Naprawa ścieżki albo powrót do TCP zależy od trzech rzeczy. Po pierwsze, czy na ścieżce jest realna utrata pakietów, czy tylko przestawianie? Po drugie, czy możesz zmienić miejsce inspekcji albo wyłączyć ten tunel ze składnika, który przestawia? Po trzecie, czy obciążenie jest wrażliwe na wzorzec zawieszeń, na przykład wiele multipleksowanych sesji dzielących jedno łącze?
Jeśli pierwsza odpowiedź to utrata, a druga brzmi nie,TCP na 443 jest pragmatycznym rozwiązaniem zastępczym. Jeśli druga odpowiedź brzmi tak, napraw ścieżkę i zostaw UDP.
Czytaj zapis firewalla, a nie błąd aplikacji
Aplikacja zgłasza przekroczenie czasu, co nic nie mówi o przyczynie. Własny log firewalla to miejsce, w którym pojawia się odrzucenie lub blokada, więc filtruj po adresach bazy danych i aplikacji i szukaj odrzuceń oraz akceptacji.Moduły zapobiegania zagrożeniom mogą odrzucać pakiety bez generowania błędu na poziomie aplikacji, a to dokładnie kształt zapytania, które się zawiesza. Cisza w logu też jest daną: wskazuje coś, co nie loguje, na przykład przestawianie.
Sprawdź też klaster. Źle skonfigurowany klaster może trzymać sesję w tabeli stanów na jednym członie, podczas gdy pakiety idą ścieżką innego członu, więc odpowiedzi docierają tam, gdzie nie ma stanu. Takie zawieszenia wyglądają losowo i nie korelują z obciążeniem.
Porównaj oba końce, zanim cokolwiek zmienisz, i porównuj kolejność przychodzenia, a nie liczbę pakietów:
tcpdump -ni any udp port 4500 -w /tmp/encap.pcap
tcpdump -ni any tcp port 5432 -w /tmp/inner.pcapIle TCP na 443 naprawdę cię kosztuje
Przeniesienie tunelu na TCP usuwa objaw przestawiania, bo pośrednik widzi teraz uporządkowany strumień. Tworzy też TCP po TCP. Zewnętrzne połączenie retransmituje to, co wewnętrzne już retransmitowało, a jedna utrata może zatrzymać wszystkie multipleksowane sesje naraz. Na czystej ścieżce jest to niewidoczne. Na ścieżce z utratami lekarstwo jest gorsze od objawu.
Zamiana jest do przyjęcia, gdy alternatywą jest brak łączności, i powinna być udokumentowana jako wyjątek z właścicielem, a nie przyjmowana jako norma.
Zapisz transport, port, przykładowe zapytanie i zmierzony wynik plus datę. Bez tego zapisu następny inżynier powtórzy eksperyment, a wyjątek po cichu stanie się architekturą.
Utrzymuj decyzję w stanie do przeglądu
Diagnoza ścieżki szybko się starzeje. Pośrednik jest wymieniany, konfiguracja modułu się zmienia, łącze jest modernizowane, a powód dla TCP na 443 znika, podczas gdy konfiguracja zostaje. Ustaw datę przeglądu wyjątku i nazwij warunek, który pozwoliłby wrócić do UDP.
Przetestuj oba transporty małym zapytaniem i dużym zbiorem wyników. Przestawianie objawia się zawieszeniami zależnymi od rozmiaru, a usterka nasłuchu zatrzymuje oba rozmiary jednakowo.