En fråga som hänger efter TCP-handskakningen är inte ett routingproblem. Rutfel får handskakningen att misslyckas, så en session som etableras och sedan tystnar pekar in i vägen: inspektion, MTU eller hur tunnelns UDP-paket anländer. Beslutet framför dig är om du ska reparera den vägen eller flytta tunneln till TCP. Tre villkor avgör det, och inget av dem handlar om databasen.

Klassificera stoppen innan du skyller på tunneln

Fyra utfall ser likadana ut för en användare och betyder helt olika saker för en ingenjör.

What the client seesWhat it rules out
Connection refusedNothing is listening on the address and port the client reached
Timeout before the handshakeA filter, a missing route, or the wrong address
Handshake completes, query hangsThe session exists, so look at inspection, MTU and packet order
Stalls that recover on retryOften reordering, or a state table entry expiring

Bara de två sista raderna motiverar tid på tunneln. En nekad anslutning över en VPN är oftast databasen som bara lyssnar på loopback, vilket är ett lyssnarproblem, och en timeout före handskakningen är ett filter eller en rutt. Ingen av dem blir bättre av att ändra inkapslingen.

Skriv klassificeringen i ärendet först. Det är det billigaste steget och tar bort större delen av sökutrymmet.

Tre villkor som avgör UDP kontra TCP

Inkapslad IPsec-trafik går på UDP, och UDP ger vägen frihet att omordna och släppa utan att berätta det för någon. När omordningen trycker paket utanför tunnelns anti-replay-fönster kastas de tyst och den inre TCP-sessionen väntar bara. Det är mekanismen bakom en handskakning som lyckas och en fråga som aldrig kommer tillbaka.

Att reparera vägen eller falla tillbaka på TCP beror på tre saker. För det första, finns det verklig paketförlust på vägen, eller bara omordning? För det andra, kan du ändra var inspektionen sker, eller utesluta den här tunneln från komponenten som omordnar? För det tredje, är arbetsbelastningen känslig för stängningsmönstret, till exempel många multiplexade sessioner som delar en länk?

Om det första svaret är förlust och det andra är nej,är TCP på 443 den pragmatiska reservlösningen. Om det andra svaret är ja, reparera vägen och behåll UDP.

Läs brandväggens post, inte applikationens fel

Applikationen rapporterar en timeout, vilket inte säger något om orsaken. Brandväggens egen logg är platsen där kast eller blockering visas, så filtrera på databasens och applikationens adresser och leta efter kast såväl som accept.Blad för hotförebyggande kan kasta paket utan att generera ett fel på applikationsnivå, och det är precis formen på en fråga som hänger. Tystnad i loggen är också data: den pekar på något som inte loggar, som omordning.

Kontrollera även klustret. Ett felkonfigurerat kluster kan hålla en session i tillståndstabellen på en medlem medan paketen tar en annan medlems väg, så svar anländer där ingen tillstånd finns. Sådana stopp verkar slumpmässiga och korrelerar inte med last.

Jämför båda ändarna innan du ändrar något, och jämför ankomstordning i stället för paketantal:

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

Vad TCP på 443 faktiskt kostar dig

Att flytta tunneln till TCP tar bort omordningssymtomet, eftersom mellanliggande utrustning nu ser ett ordnat flöde. Det skapar också TCP över TCP. Den yttre anslutningen skickar om det den inre redan skickat om, och en enda förlust kan stoppa alla multiplexade sessioner på en gång. På en ren väg är det osynligt. På en med förluster är kuren värre än symtomet.

Byten är acceptabel när alternativet är ingen anslutning, och den bör dokumenteras som ett undantag med en ägare i stället för att absorberas som normalt.

Notera transporten, porten, en exempelfråga och det uppmätta resultatet, plus datumet. Utan den posten upprepar nästa ingenjör experimentet, och undantaget blir tyst arkitekturen.

Håll beslutet granskningsbart

En vägdiagnos åldras snabbt. Utrustningen byts ut, bladkonfigurationen ändras, länken uppgraderas, och skälet till TCP på 443 försvinner medan konfigurationen blir kvar. Sätt ett granskningsdatum på undantaget och namnge villkoret som skulle låta dig gå tillbaka till UDP.

Testa båda transporterna med en liten fråga och med en stor resultatmängd. Omordning visar sig som storleksberoende stopp, medan ett lyssnarfel stoppar båda storlekarna lika mycket.

Relaterade artiklar