Ping fra IPsec-gatewayen bruker en annen kildeadresse

Send ping til den andre siden fra IPsec-gatewayen, få ikke svar og konkluder med at tunnelen er brutt, mens hver arbeidslast bak gatewayen sender trafikk normalt. De to resultatene motsier ikke hverandre. Et ping som startes på gatewayen, er en pakke med lokal kilde, og gatewayen velger en kildeadresse fra sin egen rutetabell. Det valget kan avvike fra adressene som den virkelige trafikken på stedet bruker, noe som endrer hvilken policy som passer, og hvilken returrute som gjelder. Bestem hva testen skal bevise før du leser noe inn i resultatet.

Tre forskjellige spørsmål et ping kan besvare

Det første spørsmålet er om den fjerne enden i det hele tatt er tilgjengelig fra denne verten. Det andre er om tunnelens selectors eller den rutebaserte policyen tillater trafikk fra en bestemt kilde. Det tredje er om videreformidlet trafikk fra en arbeidslast bak gatewayen virker ende til ende. Én kommando kan ikke besvare alle tre, og kildeadressen er det som skiller dem.

Velg spørsmålet først. Ellers blir et mislykket ping bevis for den teorien du allerede hadde.

Hvorfor gatewayen velger en adresse du ikke forventet

Når du pinger en destinasjon, velger den lokale stakken en kilde fra ruten som passer til den. På en rutebasert tunnel kan det være lenkeadressen til tunnelgrensesnittet, som i mange stedsdesign er et 169.254.x.x-par valgt for punkt-til-punkt-hoppet. Disse adressene finnes for at lenken skal virke; de annonseres ikke som applikasjonskildenett på den fjerne siden.

Dermed kan den fjerne enden motta en ekkoanmodning fra en adresse den ikke har returrute til, eller fra en som ingen selector passer til. Tunnelen kan være sunn, og pinget kan likevel feile, og det er nettopp den falske negativen denne artikkelen handler om.

Velg kilden bevisst

På en kontrollert Linux-gateway velger du en kilde som allerede er tildelt lokalt: ping -c 4 -I 10.30.0.1 10.40.0.20. Adressene her er illustrative, så bytt inn gatewayens virkelige indre adresse og en virkelig fjern destinasjon, og bekreft at kilden du velger tilhører denne enheten og tillates av policyen på stedet.

Lån ikke adressen til en arbeidslast til testen. Å etterligne en vert som ikke er tildelt gatewayen, skaper et resultat ingen kan gjenskape, og på noen stakker feiler det på måter som ligner en tunnelfeil.

Les returveien, ikke bare forespørselen

Kontroller hvilken kilde som faktisk ankommer den fjerne destinasjonen, inkludert eventuell bevisst oversettelse underveis. Kontroller deretter den fjerne sidens returrute til den kilden og selectorene eller policyen som tillater den. En forespørsel som ankommer med en uventet kilde, er et ruting- og policyspørsmål, ikke et kryptografisk.

Det er også her en opptak hjelper mer enn et nytt ping: den viser kilden den fjerne enden så, og det er adressen svaret dens må nå.

Test deretter arbeidslasten

Den avgjørende testen er et ping fra en vanlig vert bak gatewayen til en vanlig vert bak den fjerne gatewayen. Det øver gatewayens videreformidlingsrolle, den virkelige applikasjonskilden og den sanne returveien, og det er strømmen brukerne bryr seg om.

Hold resultatene atskilt i notatene dine: tilgjengelighet fra gatewayen, policyadgang for en valgt kilde og videreformidlet trafikk. Et vellykket festet ping er nyttig bevis for at tunnelen bærer noe; det er ikke bevis for at hver videreformidlet strøm virker. Og en automatisk valgt gatewaykilde som ikke kan nås, er ikke bevis for at stedets tunnel er nede.

Ikke legg til en bred rute for 169.254.0.0/16 bare for å få ett diagnostisk svar. Det bytter en villedende test mot en permanent rutebeslutning, og neste person arver den uten konteksten.