Du fekk tunnelen opp, rekey-timaren tel ned, og begge retningar viser framleis null pakkar. Ingenting i det talparet seier at peer-en avviste tunnelen din: ein installert CHILD SA med ledige teljarar er den normale tilstanden til ein assosiasjon som ingenting har matcha enno. Arbeidet er å bevise at ein pakke burde ha matcha, og deretter finne punktet der han forlét vegen selektorane skildrar. Gjer det éin gong, i rekkjefølgje, og hald førespurnaden identisk mellom køyringane.

Kva ein nullteljar faktisk beviser

Ein CHILD SA er eit selektorpar pluss nøklane og SPI-en som krypterer trafikk som fell innanfor desse områda. Å installere ein tyder berre at begge peer-ane vart samde om områda og utleidde nøklar; kjernen held han i timar utan at ein einaste pakke kjem inn. Spørsmålet er derfor aldri om tunnelen finst, men om noka pakke testen din sende fall innanfor områda dei to peer-ane forhandla fram. Viss ingen gjorde det, blir teljarane ståande på null og assosiasjonen går ut ubrukt ved slutten av levetida.

Den skilnaden endrar kva du undersøkjer først. Eit avvist forslag, ein autentiseringsfeil eller ein døyande IKE SA dukkar alle opp i loggen eller i SA-lista, ikkje som ein stille null. Ein tunnel som forhandlar reint og deretter blir ledig, peikar i staden på matching, ruting eller opphavet til testtrafikken.

Send ein straum du kan skildre før du sender han

Vel ein destinasjon inne i det verna subnettet og opne ei ny tilkopling til han; ei side du lasta for ein time sidan kan bli servert frå cachen, og eit bufre svar rører aldri tunnelen. Skriv deretter ned fire verdiar medan førespurnaden framleis er hypotetisk: kjeldeadressa applikasjonen vil binde, destinasjonen, adressefamilien og namnet eller selektorparet til barnet du overvaker. Den registreringa er det som gjer ein flat teljar om til ei prøvbar påstand.

Kjeldeadressa er verdien folk hoppar over, og det er den som øydelegg testen oftast. Ein laptop med ei kabeladresse, ei Wi-Fi-adresse og ei tunneladresse kan binde kva som helst av dei avhengig av ruteoppslaget, og berre éi kan liggje innanfor det forhandla området. Bruk eit verktøy som lèt deg låse kjelda, til dømes ping -I 10.1.0.5 10.2.0.9 eller curl --interface 10.1.0.5, slik at pakken ikkje stille kan velje ei anna adresse. Når den låste køyringa flyttar teljarane og den ulåste ikkje gjer det, har du funne eit ruteproblem og ikkje eit IPsec-problem.

Kva tal du skal lese, og kvar dei bur

På Linux skriv ip -s xfrm state ut kvar assosiasjon med ei lifetime current:-linje der byte- og pakketotalen høyrer til den SA-en åleine, følgd av ei stats:-linje for replay- og feilteljingar. Hos ein strongSwan-peer skriv swanctl --list-sas ut éi in-linje og éi out-linje per installert barn, kvar med ei byte- og ei pakketeljing til slutt; dei eldre stroke-verktøya kallar det same paret bytes_i og bytes_o. Les kvar retning for seg, sidan den som blei ståande flat er funnet. Å leggje dei saman skjuler nettopp asymmetrien du leitar etter.

Begge visingane er per assosiasjon, så ein rekey installerar eit nytt SPI-par og utgangspunktet ditt går tilbake til null utan at noko er øydelagt. Noter SPI-en du overvaker før rekey-timaren går av, elles samanliknar du ein ny SA med eit gamalt tal. Viss utgåande stig medan inngåande blir flat, har selektoren matcha og svaret kom aldri tilbake, noko som flyttar undersøkinga til videresendinga til peer-en og til hans eigen policy. strongSwan sin IKEv2-konfigurasjonsdokumentasjon dekkjer livssyklusen til barn-SA-en og rekey-tidspunktet bak desse tala.

Observasjonspunktet er ein eigen variabel frå opphavet til pakken. Ein maskinvareoffload kan auke teljarane til assosiasjonen medan eit programvareopptak på grensesnittet ikkje viser noko, fordi offloada pakkar hoppar over kroken opptaket sit på, og inngåande kan avvike på same måte. Når dei to er usamde, bruk teljarane til å svare på om noko matcha og opptaket til å svare på korleis pakken såg ut.

Rute, selektorar og kvar pakken blei fødd

Samanlikn tre ting side om side: ruta kjernen vel for destinasjonen din, policyen som styrer trafikk inn i tunnelen, og selektorparet barnet forhandla fram. ip route get 10.2.0.9 from 10.1.0.5 namngir grensesnittet og kjelda kjernen ville brukt, som ofte ikkje er paret du antok. ip xfrm policy viser malane og selektorane som er installerte lokalt, medan swanctl --list-sas viser kva peer-en var samd i. Eit oppslag som sender pakken ut av det fysiske grensesnittet når aldri policyen i det heile, så teljarane kan ikkje flytte seg.

Feilmatch kjem i fleire former som ser identiske ut frå ein teljar. Ein IPv6-destinasjon utanfor ein IPv4-selektor, ei kjeldeadresse frå feil subnett og ein policy som er smalare enn barnet gir alle den same nullen. Fiks den smalaste årsaka først, fordi å utvide ein selektor berre for å flytte eit tal endrar kva tunnelen vernar.

Så er det opphavet til pakken, fella ein gateway set for sin eigen operatør. Trafikk gatewayen genererer sjølv blir matcha mot output-policyen, medan ein pakke han videresender for ein klient blir matcha mot forward-policyen, så ein ping frå boksen kan lukkast på ein veg ingen klient nokosinne tek.

Éi reversibel endring og ein rapport som toler gjennomgang

Endre eitt enkelt element, gjenta den identiske førespurnaden og les dei same teljarane. Å tømme alle brannmurreglar eller byte ut alle selektorar samtidig vil flytte eit tal og øydeleggje beviset som fortalde deg kvifor. Viss den andre køyringa framleis viser null, har du eliminert éin hypotese i staden for å kaste bort ettermiddagen.

Skriv funnet i ein form nokon andre kan gjenskape: namnet på barnet, godtekne område, kjelda du låste, destinasjonen du testa, retninga som blei ståande på null, og SPI-en du las. Den setninga skil ein assosiasjon ingen brukte frå ein ekstern applikasjon som tok imot trafikken og avviste han. Rull endringa tilbake når ho ikkje flytta teljarane, og behald registreringa; neste person startar der du stoppa. Ingenting i tunnelen trong å byggjast på nytt for noko av dette, og det er poenget med å sjekke matching før du rører konfigurasjonen.

Relaterte artiklar