Du fikk tunnelen opp, rekey-timeren teller ned, og begge retninger viser fortsatt null pakker. Ingenting i det tallparet sier at peer-en avviste tunnelen din: en installert CHILD SA med ledige tellere er den normale tilstanden til en assosiasjon som ingenting har matchet ennå. Arbeidet er å bevise at en pakke burde ha matchet, og deretter finne punktet der den forlot veien selektorene beskriver. Gjør det én gang, i rekkefølge, og hold forespørselen identisk mellom kjøringene.

Hva en nullteller faktisk beviser

En CHILD SA er et selektorpar pluss nøklene og SPI-en som krypterer trafikk som faller innenfor disse områdene. Å installere en betyr bare at begge peer-ene ble enige om områdene og utledet nøkler; kjernen holder den i timer uten at en eneste pakke kommer inn. Spørsmålet er derfor aldri om tunnelen finnes, men om noen pakke testen din sendte falt innenfor områdene de to peer-ene forhandlet fram. Hvis ingen gjorde det, blir tellerne stående på null og assosiasjonen utløper ubrukt ved slutten av levetiden.

Den forskjellen endrer hva du undersøker først. Et avvist forslag, en autentiseringsfeil eller en døende IKE SA dukker alle opp i loggen eller i SA-listen, ikke som en stille null. En tunnel som forhandler rent og deretter blir ledig, peker i stedet på matching, ruting eller opprinnelsen til testtrafikken.

Send en strøm du kan beskrive før du sender den

Velg en destinasjon inne i det beskyttede subnettet og åpne en ny tilkobling til den; en side du lastet for en time siden kan bli servert fra cachen, og et bufret svar berører aldri tunnelen. Skriv deretter ned fire verdier mens forespørselen fortsatt er hypotetisk: kildeadressen applikasjonen vil binde, destinasjonen, adressefamilien og navnet eller selektorparet til barnet du overvåker. Den registreringen er det som gjør en flat teller om til en testbar påstand.

Kildeadressen er verdien folk hopper over, og det er den som ødelegger testen oftest. En laptop med en kablet adresse, en Wi-Fi-adresse og en tunneladresse kan binde hvilken som helst av dem avhengig av ruteoppslaget, og bare én kan ligge innenfor det forhandlede området. Bruk et verktøy som lar deg låse kilden, for eksempel ping -I 10.1.0.5 10.2.0.9 eller curl --interface 10.1.0.5, slik at pakken ikke stille kan velge en annen adresse. Når den låste kjøringen flytter tellerne og den ulåste ikke gjør det, har du funnet et ruteproblem og ikke et IPsec-problem.

Hvilke tall du skal lese, og hvor de bor

På Linux skriver ip -s xfrm state ut hver assosiasjon med en lifetime current:-linje der byte- og pakketotalen tilhører den SA-en alene, etterfulgt av en stats:-linje for replay- og feiltellinger. Hos en strongSwan-peer skriver swanctl --list-sas ut én in-linje og én out-linje per installert barn, hver med en byte- og en pakketelling til slutt; de eldre stroke-verktøyene kaller det samme paret bytes_i og bytes_o. Les begge retningene hver for seg, for den som ble stående flat er funnet. Å legge dem sammen skjuler nettopp asymmetrien du leter etter.

Begge visningene er per assosiasjon, så en rekey installerer et nytt SPI-par og utgangspunktet ditt går tilbake til null uten at noe er ødelagt. Noter SPI-en du overvåker før rekey-timeren utløses, ellers sammenligner du en ny SA med et gammelt tall. Hvis utgående stiger mens inngående blir flat, har selektoren matchet og svaret kom aldri tilbake, noe som flytter undersøkelsen til peer-ens videresending og dens egen policy. strongSwan sin IKEv2-konfigurasjonsdokumentasjon dekker livssyklusen til barn-SA-en og rekey-tidspunktet bak disse tallene.

Observasjonspunktet er en egen variabel fra pakkens opprinnelse. En maskinvareoffload kan øke assosiasjonens tellere mens en programvareopptak på grensesnittet ikke viser noe, fordi offloadede pakker hopper over kroken opptaket sitter på, og inngående kan avvike på samme måte. Når de to er uenige, bruk tellerne til å svare på om noe matchet og opptaket til å svare på hvordan pakken så ut.

Rute, selektorer og hvor pakken ble født

Sammenlign tre ting side om side: ruten kjernen velger for destinasjonen din, policyen som styrer trafikk inn i tunnelen, og selektorparat barnet forhandlet fram. ip route get 10.2.0.9 from 10.1.0.5 navngir grensesnittet og kilden kjernen ville brukt, som ofte ikke er paret du antok. ip xfrm policy viser malene og selektorene som er installert lokalt, mens swanctl --list-sas viser hva peer-en ble enige om. Et oppslag som sender pakken ut av det fysiske grensesnittet når aldri policyen i det hele tatt, så tellerne kan ikke flytte seg.

Feilmatch kommer i flere former som ser identiske ut fra en teller. En IPv6-destinasjon utenfor en IPv4-selektor, en kildeadresse fra feil subnett og en policy som er smalere enn barnet gir alle den samme nullen. Fiks den smaleste årsaken først, fordi å utvide en selektor bare for å flytte et tall endrer hva tunnelen beskytter.

Så er det pakkens opprinnelse, fellen en gateway setter for sin egen operatør. Trafikk gatewayen genererer selv matches mot output-policyen, mens en pakke den videresender for en klient matches mot forward-policyen, så en ping fra boksen kan lykkes på en vei ingen klient noen gang tar.

Én reversibel endring og en rapport som tåler gjennomgang

Endre ett enkelt element, gjenta den identiske forespørselen og les de samme tellerne. Å tømme alle brannmurregler eller bytte ut alle selektorer samtidig vil flytte et tall og ødelegge beviset som fortalte deg hvorfor. Hvis den andre kjøringen fortsatt viser null, har du eliminert én hypotese i stedet for å kaste bort ettermiddagen.

Skriv funnet i en form noen andre kan gjenskape: barnets navn, godtatte områder, kilden du låste, destinasjonen du testet, retningen som ble stående på null, og SPI-en du leste. Den setningen skiller en assosiasjon ingen brukte fra en ekstern applikasjon som mottok trafikken og avviste den. Rull endringen tilbake når den ikke flyttet tellerne, og behold registreringen; neste person starter der du stoppet. Ingenting i tunnelen trengte å bygges på nytt for noe av dette, og det er poenget med å sjekke matching før du rører konfigurasjonen.

Relaterte artikler