Ping fra IPsec-gatewayen bruger en anden kildeadresse

Send en ping fra IPsec-gatewayen til den anden side, få intet svar og konkluder, at tunnelen er brudt, mens hver arbejdsbyrde bag gatewayen sender trafik normalt. De to resultater modsiger ikke hinanden. En ping, der startes på gatewayen, er en pakke med lokal kilde, og gatewayen vælger en kildeadresse fra sin egen rutetabel. Det valg kan afvige fra de adresser, som den virkelige trafik på stedet bruger, hvilket ændrer, hvilken politik der matcher, og hvilken returrute der gælder. Beslut, hvad testen skal bevise, før du læser noget ind i resultatet.

Tre forskellige spørgsmål, som en ping kan besvare

Det første spørgsmål er, om den fjerne ende overhovedet kan nås fra denne vært. Det andet er, om tunnelens selectors eller den rutebaserede politik tillader trafik fra en bestemt kilde. Det tredje er, om videreformidlet trafik fra en arbejdsbyrde bag gatewayen virker ende til ende. Én kommando kan ikke besvare alle tre, og kildeadressen er det, der skiller dem.

Vælg spørgsmålet først. Ellers bliver en mislykket ping bevis for den teori, du allerede havde.

Hvorfor gatewayen vælger en adresse, du ikke forventede

Når du pinger en destination, vælger den lokale stak en kilde fra den rute, der matcher den. På en rutebaseret tunnel kan det være linkadressen på tunnelinterfacet, som i mange stedsdesign er et 169.254.x.x-par valgt til punkt-til-punkt-hoppet. Disse adresser findes for at få linket til at virke; de annonceres ikke som applikationskildenettet på den fjerne side.

Så den fjerne ende kan modtage en ekkoanmodning fra en adresse, den ikke har en returrute til, eller en som ingen selector matcher. Tunnelen kan være sund, og pinget kan stadig fejle, og det er præcis den falske negativ, denne artikel handler om.

Vælg kilden bevidst

På en kontrolleret Linux-gateway skal du vælge en kilde, der allerede er tildelt lokalt: ping -c 4 -I 10.30.0.1 10.40.0.20. Adresserne her er illustrative, så indsæt gatewayens rigtige indre adresse og en rigtig fjern destination, og bekræft, at den kilde, du vælger, tilhører denne enhed og tillades af politikken på stedet.

Lån ikke en arbejdsbyrdes adresse til testen. At efterligne en vært, der ikke er tildelt gatewayen, skaber et resultat, ingen kan genskabe, og på nogle stakke fejler det på måder, der ligner en tunnelejl.

Læs returvejen, ikke bare anmodningen

Kontroller, hvilken kilde der faktisk ankommer til den fjerne destination, inklusive enhver bevidst oversættelse undervejs. Kontroller derefter den fjerne sides returrute til den kilde og de selectors eller den politik, der tillader det. En anmodning, der ankommer med en uventet kilde, er et rutnings- og politikspørgsmål, ikke et kryptografisk.

Det er også her, en optagelse hjælper mere end endnu en ping: den viser den kilde, den fjerne ende så, og det er den adresse, dens svar skal nå.

Test derefter arbejdsbyrden

Den afgørende test er en ping fra en almindelig vært bag gatewayen til en almindelig vært bag den fjerne gateway. Det øver gatewayens videresendelsesrolle, den virkelige applikationskilde og den sande returvej, og det er den strøm, brugerne bekymrer sig om.

Hold resultaterne adskilt i dine noter: tilgængelighed fra gatewayen, politikadgang for en valgt kilde og videreformidlet trafik. Et vellykket fastgjort ping er nyttigt bevis for, at tunnelen bærer noget; det er ikke bevis for, at enhver videreformidlet strøm virker. Og en automatisk valgt gatewaykilde, der ikke kan nås, er ikke bevis for, at stedets tunnel er nede.

Tilføj ikke en bred rute for 169.254.0.0/16 blot for at få ét diagnostisk svar. Det bytter en vildledende test for en permanent rutningsbeslutning, og den næste person arver den uden konteksten.