IPsec-policy sluker den lokale trafikken din: slik gjenkjenner du det

Skriveren på skrivebordet slutter å svare i det øyeblikket tunnelen kommer opp, og ingenting i tunnelkonfigurasjonen nevner skriveren. Det som vanligvis har skjedd, er at et beskyttet område ble skrevet bredt nok til å omfatte den, så maskinen prøver nå å kryptere trafikk som skulle blitt på det lokale segmentet. Å lese den installerte policyen forklarer oppfangningen; å begrense den på riktig sted holder fjernrtrafikken beskyttet. Turen fra den mislykkede forespørselen til den samsvarende policyen tar noen minutter.

Følg flyten før du endrer en velger

Start ved den mislykkede forespørselen og skriv ned fire verdier: kildeadressen maskinen bruker, den nøyaktige destinasjonen, ruten kjernen velger, og policyen som passer til det paret.

Disse fire fakta avgjør om oppfangningen er bevisst eller tilfeldig. En destinasjon som faller innenfor fjernvelgeren, beskyttes ved design, selv om designet var feil. En destinasjon utenfor den som likevel fanges opp, betyr at noe annet passer, og det hjelper ikke å endre velgeren. Begge tilfellene er vanlige, og én kommando skiller dem.

Gjør dette før du redigerer noe, for det interessante tilfellet er det lokale subnettet som overlapper med et privatområde forbindelsen beskytter. Kjente prefikser som 192.168.0.0/16 finnes i mange nettverk, og en velger skrevet for ett av dem kan stille dekke ditt eget.

Tre typer lokalt som oppfører seg forskjellig

En destinasjon som er tildelt denne verten, en destinasjon på samme lenke og en destinasjon bak et annet grensesnitt er tre forskjellige tilfeller. Kjernen behandler hver av dem forskjellig når den avgjør om trafikken trenger beskyttelse.

Trafikk som gatewayen selv genererer, er heller ikke det samme som trafikk videresendt fra en klient. En policy som ser riktig ut for videresendt trafikk, kan fange gatewayens egen administrasjonssesjon, og det er slik en administrator mister tilgangen mens han reparerer tunnelen.

Den nyttige vanen er å navngi tilfellet høyt: kommer denne pakken fra meg, til lenken min eller gjennom meg? Hvert svar peker på et annet sted å begrense. Å skrive ned tilfellet hindrer også neste person i å gjøre samme arbeid på nytt.

Når det beskyttede området er et helt privat rom, kan alle tre tilfellene falle inn i det samtidig, og symptomet blir en maskin som ikke når noe annet enn tunnelendepunktet.

Les den installerte policyen, ikke filen

Konfigurasjonsfiler beskriver intensjonen; kjernen holder policyene som faktisk passer. Vis begge, og behandle et avvik som det første funnet.

Disse kommandoene viser den valgte ruten til destinasjonen og de installerte policyene i hver retning:

ip route get 192.168.50.20
ip xfrm policy list
sudo swanctl --list-conns

Ruten forteller deg hvilket grensesnitt pakken ville bruke. Policylisten forteller deg om det deretter brukes en mal på pakken, og forbindelseslisten viser hvilke velgere daemonen tror den har installert. Hvis destinasjonen dukker opp i en fjernvelger, har du funnet oppfangningen uten å gjette.

Begrens velgeren eller omgå destinasjonen

Det finnes to støttede reparasjoner, og de svarer på forskjellige spørsmål. Å begrense velgeren sier at denne forbindelsen bare beskytter et mindre område, noe som er riktig når det bredere området var en feil. Å legge til en omgåelse sier at denne bestemte destinasjonen aldri skal beskyttes, noe som er riktig når det beskyttede området virkelig er bredt og én destinasjon er unntaket.

Velg den første når du kan, fordi en mindre velger er lettere å resonnere om og vises i forbindelsesdefinisjonen. Velg den andre når det brede området er bevisst og unntaket er en enkelt vert eller et subnett du kan navngi.

Begge hører til konfigurasjonen som eier forbindelsen. En kjøretidsregel lagt til for hånd forsvinner ved neste gjenoppkobling, og feilen kommer tilbake på et tidspunkt da ingen husker workarounden.

Unntak som overlever reinstallasjon

Etter endringen gjentar du den samme ufarlige forespørselen og ser på de samme tellerne. Den lokale destinasjonen bør svare, og den tiltenkte fjerndestinasjonen bør fortsatt vise kryptert trafikk.

Disse to kontrollene bekrefter at unntaket overlevde og beskyttelsen ikke:

ip xfrm policy list | grep -c out
ping -c 3 192.168.50.20

Koble deretter fra og tilbake til tunnelen med vilje, og gjenta begge. Et unntak som virker før gjenoppkoblingen og feiler etter, ble brukt på feil lag, og det er den vanligste måten dette problemet kommer tilbake på.