Ping från IPsec-gatewayen använder en annan källadress

Pinga den andra sidan från IPsec-gatewayen, få inget svar och dra slutsatsen att tunneln är trasig, medan varje arbetsbelastning bakom gatewayen skickar trafik normalt. De två resultaten motsäger inte varandra. Ett ping som startas på gatewayen är ett paket med lokal källa, och gatewayen väljer en källadress från sin egen routingtabell. Det valet kan skilja sig från de adresser som den verkliga platstrafiken använder, vilket ändrar vilken policy som matchar och vilken returväg som gäller. Bestäm vad testet ska bevisa innan du läser in något i resultatet.

Tre olika frågor som ett ping kan besvara

Den första frågan är om den bortre änden över huvud taget går att nå från denna värd. Den andra är om tunnelns selectors eller den ruttbaserade policyn tillåter trafik från en viss källa. Den tredje är om vidarebefordrad trafik från en arbetsbelastning bakom gatewayen fungerar från ände till ände. Ett enda kommando kan inte besvara alla tre, och källadressen är det som skiljer dem.

Välj frågan först. Annars blir ett misslyckat ping bevis för den teori du redan hade.

Varför gatewayen väljer en adress du inte förväntade dig

När du pingar ett mål väljer den lokala stacken en källa från rutten som matchar det. På en ruttbaserad tunnel kan det vara länkadressen för tunnelgränssnittet, som i många platsdesigner är ett 169.254.x.x-par valt för punkt-till-punkt-hoppet. Dessa adresser finns för att länken ska fungera; de annonseras inte som applikationskällnät på den bortre sidan.

Därför kan den bortre änden ta emot en ekoanmodning från en adress som den inte har någon returväg till, eller från en som ingen selector matchar. Tunneln kan vara frisk och pinget kan ändå misslyckas, och det är precis den falska negativen som den här artikeln handlar om.

Välj källan medvetet

På en kontrollerad Linux-gateway väljer du en källa som redan är tilldelad lokalt: ping -c 4 -I 10.30.0.1 10.40.0.20. Adresserna här är illustrativa, så byt ut dem mot gatewayens verkliga inre adress och ett verkligt fjärrmål, och bekräfta att källan du väljer tillhör den här enheten och tillåts av platsens policy.

Låna inte en arbetsbelastnings adress till testet. Att utge sig för att vara en värd som inte är tilldelad gatewayen skapar ett resultat som ingen kan återskapa, och på vissa stackar misslyckas det på sätt som ser ut som ett tunnelfel.

Läs returvägen, inte bara begäran

Kontrollera vilken källa som faktiskt når fjärrmålet, inklusive eventuell avsiktlig översättning på vägen. Kontrollera sedan den bortre sidans returväg till den källan och de selectors eller den policy som tillåter den. En begäran som kommer med en oväntad källa är en routing- och policyfråga, inte en kryptografisk.

Här hjälper också en paketinsamling mer än ännu ett ping: den visar den källa som den bortre änden såg, och det är adressen som dess svar måste nå.

Testa sedan arbetsbelastningen

Det avgörande testet är ett ping från en vanlig värd bakom gatewayen till en vanlig värd bakom den bortre gatewayen. Det övar gatewayens vidarebefordringsroll, den verkliga applikationskällan och den sanna returvägen, och det är det flöde användarna bryr sig om.

Håll resultaten åtskilda i dina anteckningar: nåbarhet från gatewayen, policytillstånd för en vald källa och vidarebefordrad trafik. Ett lyckat fäst ping är ett användbart bevis för att tunneln bär något; det är inte bevis för att varje vidarebefordrat flöde fungerar. Och en automatiskt vald gatewaykälla som inte går att nå är inte bevis för att platsens tunnel är nere.

Lägg inte till en bred rutt för 169.254.0.0/16 bara för att få ett diagnostiskt svar. Det byter ett vilseledande test mot ett permanent routingbeslut, och nästa person ärver det utan sammanhanget.