Ping vanaf de IPsec-gateway gebruikt een ander bronadres

Ping de andere kant vanaf de IPsec-gateway, krijg geen antwoord en concludeer dat de tunnel kapot is, terwijl elke workload achter de gateway normaal verkeer doorlaat. De twee resultaten spreken elkaar niet tegen. Een ping die op de gateway start, is een pakket met een lokale bron, en de gateway kiest een bronadres uit zijn eigen routetabel. Die keuze kan afwijken van de adressen die het echte siteverkeer gebruikt, waardoor verandert welk beleid past en welke retourroute geldt. Bepaal wat de test moet bewijzen voordat je iets in het resultaat leest.

Drie verschillende vragen die een ping kan beantwoorden

De eerste vraag is of de verre kant überhaupt bereikbaar is vanaf deze host. De tweede is of de selectors van de tunnel of het op routes gebaseerde beleid verkeer van een bepaalde bron toelaten. De derde is of doorgestuurd verkeer van een workload achter de gateway van begin tot eind werkt. Eén commando kan niet alle drie beantwoorden, en het bronadres is wat ze scheidt.

Kies eerst de vraag. Anders wordt een mislukte ping bewijs voor de theorie die je al had.

Waarom de gateway een adres kiest dat je niet verwachtte

Wanneer je een bestemming pingt, kiest de lokale stack een bron uit de route die daarbij past. Op een op routes gebaseerde tunnel kan dat het linkadres van de tunnelinterface zijn, dat in veel siteontwerpen een 169.254.x.x-paar is dat voor de punt-naar-punt-hop is gekozen. Die adressen bestaan om de link te laten werken; ze worden aan de verre kant niet als applicatiebronnetwerken aangekondigd.

Zo kan de verre kant een echo-verzoek ontvangen van een adres waarnaar hij geen retourroute heeft, of van een adres waar geen enkele selector bij past. De tunnel kan gezond zijn en de ping kan toch mislukken, en dat is precies de valse negatieve waar dit artikel over gaat.

Kies de bron bewust

Kies op een gecontroleerde Linux-gateway een bron die al lokaal is toegewezen: ping -c 4 -I 10.30.0.1 10.40.0.20. De adressen hier zijn illustratief, dus vervang ze door het echte interne adres van de gateway en een echte verre bestemming, en bevestig dat de bron die je kiest bij dit apparaat hoort en door het sitebeleid wordt toegelaten.

Leen geen adres van een workload voor de test. Je voordoen als een host die niet aan de gateway is toegewezen, levert een resultaat op dat niemand kan reproduceren, en op sommige stacks faalt het op manieren die op een tunnelstoring lijken.

Lees de retourroute, niet alleen het verzoek

Controleer welke bron daadwerkelijk bij de verre bestemming aankomt, inclusief eventuele bewuste vertaling onderweg. Controleer daarna de retourroute van de verre kant naar die bron en de selectors of het beleid die dat toestaan. Een verzoek dat met een onverwachte bron aankomt, is een routerings- en beleidsvraag, geen cryptografische.

Hier helpt een pakketopname ook meer dan nog een ping: die laat de bron zien die de verre kant zag, en dat is het adres dat zijn antwoord moet bereiken.

Test daarna de workload

De beslissende test is een ping van een gewone host achter de gateway naar een gewone host achter de verre gateway. Dat oefent de doorstuurrol van de gateway, de echte applicatiebron en de werkelijke retourroute, en dat is de stroom waar gebruikers om geven.

Houd de resultaten apart in je notities: bereikbaarheid vanaf de gateway, beleidstoelating voor een gekozen bron en doorgestuurd verkeer. Een geslaagde vastgezette ping is nuttig bewijs dat de tunnel iets draagt; het is geen bewijs dat elke doorgestuurde stroom werkt. En een automatisch gekozen gatewaybron die niet bereikbaar is, is geen bewijs dat de tunnel van de site plat ligt.

Voeg geen algemene route voor 169.254.0.0/16 toe alleen om één diagnostisch antwoord te krijgen. Dat ruilt een misleidende test voor een permanente routeringsbeslissing, en de volgende persoon erft die zonder de context.