Ping frå IPsec-gatewayen brukar ei anna kjeldeadresse

Send ping til den andre sida frå IPsec-gatewayen, få ikkje svar og konkluder med at tunnelen er broten, medan kvar arbeidslast bak gatewayen sender trafikk normalt. Dei to resultata seier ikkje imot kvarandre. Eit ping som blir starta på gatewayen, er ein pakke med lokal kjelde, og gatewayen vel ei kjeldeadresse frå si eiga rutetabell. Det valet kan avvike frå adressene som den verkelege trafikken på staden brukar, noko som endrar kva politikk som passar, og kva returveg som gjeld. Avgjer kva testen skal bevisa før du les noko inn i resultatet.

Tre ulike spørsmål eit ping kan svare på

Det første spørsmålet er om den fjerne enden i det heile er tilgjengeleg frå denne verten. Det andre er om selectors til tunnelen eller den rutebaserte politikken tillèt trafikk frå ei bestemd kjelde. Det tredje er om vidaresend trafikk frå ei arbeidslast bak gatewayen verkar ende til ende. Éin kommando kan ikkje svare på alle tre, og kjeldeadressa er det som skil dei.

Vel spørsmålet først. Elles blir eit mislukka ping prov for den teorien du alt hadde.

Kvifor gatewayen vel ei adresse du ikkje venta

Når du pingar ein destinasjon, vel den lokale stakken ei kjelde frå ruta som passar til han. På ein rutebasert tunnel kan det vere lenkjeadressa til tunellgrensesnittet, som i mange staddesign er eit 169.254.x.x-par valt for punkt-til-punkt-hoppet. Desse adressene finst for at lenkja skal verke; dei blir ikkje annonserte som applikasjonskjeldenett på den fjerne sida.

Dermed kan den fjerne enden ta imot ei ekko-førespurnad frå ei adresse han ikkje har returveg til, eller frå ei som ingen selector passar til. Tunnelen kan vere sunn, og pinget kan likevel feile, og det er nettopp den falske negative denne artikkelen handlar om.

Vel kjelda medvite

På ein kontrollert Linux-gateway vel du ei kjelde som alt er tildelt lokalt: ping -c 4 -I 10.30.0.1 10.40.0.20. Adressene her er illustrerande, så byt inn den verkelege indre adressa til gatewayen og ein verkeleg fjern destinasjon, og stadfest at kjelda du vel høyrer til denne eininga og blir tillaten av politikken på staden.

Lån ikkje adressa til ei arbeidslast til testen. Å etterlikne ein vert som ikkje er tildelt gatewayen, skaper eit resultat ingen kan gjenskape, og på somme stakkar feilar det på måtar som liknar ein tunellfeil.

Les returvegen, ikkje berre førespurnaden

Kontroller kva kjelde som faktisk kjem fram til den fjerne destinasjonen, inkludert eventuell medviten omsetjing undervegs. Kontroller deretter returvegen til den fjerne sida til den kjelda og selectors eller politikken som tillèt henne. Ein førespurnad som kjem med ei uventa kjelde, er eit rutings- og politiskspørsmål, ikkje eit kryptografisk.

Det er òg her ein opptak hjelper meir enn eit nytt ping: det viser kjelda den fjerne enden såg, og det er adressa svaret hans må nå.

Test deretter arbeidslasta

Den avgjerande testen er eit ping frå ein vanleg vert bak gatewayen til ein vanleg vert bak den fjerne gatewayen. Det øver vidaresendingsrolla til gatewayen, den verkelege applikasjonskjelda og den sanne returvegen, og det er straumen brukarane bryr seg om.

Hald resultata åtskilde i notata dine: tilgjenge frå gatewayen, politikk-tilgang for ei vald kjelde og vidaresend trafikk. Eit vellukka fest ping er nyttig prov for at tunnelen ber noko; det er ikkje prov for at kvar vidaresend straum verkar. Og ei automatisk vald gatewaykjelde som ikkje kan nåast, er ikkje prov for at tunnelen til staden er nede.

Ikkje legg til ei brei rute for 169.254.0.0/16 berre for å få eitt diagnostisk svar. Det byter ein villleiande test mot ei permanent ruteavgjerd, og neste person arvar henne utan konteksten.