IPsec-politik sluger din lokale trafik: sådan ser du det

Printeren på skrivebordet holder op med at svare i det øjeblik, tunnelen kommer op, og intet i tunnelkonfigurationen nævner printeren. Det, der normalt er sket, er, at et beskyttet område er skrevet bredt nok til at omfatte den, så maskinen nu prøver at kryptere trafik, som skulle være på det lokale segment. At læse den installerede politik forklarer opsnapningen; at indsnævre den det rigtige sted holder fjertrafikken beskyttet. Turen fra den fejlende anmodning til den matchende politik tager få minutter.

Følg flowet, før du ændrer en vælger

Start ved den fejlende anmodning, og skriv fire værdier ned: kildeadressen, maskinen bruger, den præcise destination, den rute kernen vælger, og den politik, der matcher det par.

De fire fakta afgør, om opsnapningen er bevidst eller utilsigtet. En destination, der ligger inde i fjernvælgeren, beskyttes ved design, selv om designet var forkert. En destination uden for den, som stadig bliver opsnappet, betyder, at noget andet matcher, og det hjælper ikke at ændre vælgeren. Begge tilfælde er almindelige, og én kommando skelner dem.

Gør det, før du redigerer noget, for det interessante tilfælde er det lokale subnet, der overlapper et privat område, som forbindelsen beskytter. Kendte præfikser som 192.168.0.0/16 optræder i mange netværk, og en vælger skrevet til et af dem kan stille dække dit eget.

Tre slags lokalt, der opfører sig forskelligt

En destination, der er tildelt denne vært, en destination på samme link og en destination bag en anden grænseflade er tre forskellige tilfælde. Kernen behandler hver af dem forskelligt, når den afgør, om trafikken skal beskyttes.

Trafik, som gatewayen selv genererer, er heller ikke det samme som trafik videresendt fra en klient. En politik, der ser korrekt ud for videresendt trafik, kan opsnappe gatewayens egen administrationssession, og det er sådan en administrator mister adgangen, mens han reparerer tunnelen.

Den nyttige vane er at navngive tilfældet højt: kommer denne pakke fra mig, til mit link eller gennem mig? Hvert svar peger på et andet sted at indsnævre. At skrive tilfældet ned forhindrer også den næste person i at gentage arbejdet.

Når det beskyttede område er et helt privat rum, kan alle tre tilfælde falde ind i det på én gang, og symptomet bliver en maskine, der ikke kan nå noget undtagen tunnelendepunktet.

Læs den installerede politik, ikke filen

Konfigurationsfiler beskriver hensigten; kernen har de politikker, der faktisk matcher. Vis begge, og behandl en uoverensstemmelse som det første fund.

Disse kommandoer viser den valgte rute til destinationen og de installerede politikker i hver retning:

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

Ruten fortæller dig, hvilken grænseflade pakken ville bruge. Politiklisten fortæller dig, om der derefter anvendes en skabelon på pakken, og forbindelseslisten viser, hvilke vælgere dæmonen mener at have installeret. Hvis destinationen optræder i en fjernvælger, har du fundet opsnapningen uden at gætte.

Indsnævr vælgeren eller omgå destinationen

Der er to understøttede reparationer, og de besvarer forskellige spørgsmål. At indsnævre vælgeren siger, at denne forbindelse kun beskytter et mindre område, hvilket er rigtigt, når det bredere område var en fejl. At tilføje en omgåelse siger, at denne specifikke destination aldrig må beskyttes, hvilket er rigtigt, når det beskyttede område virkelig er bredt, og én destination er undtagelsen.

Vælg den første, når du kan, for en mindre vælger er lettere at ræsonnere om og fremgår af forbindelsesdefinitionen. Vælg den anden, når det brede område er bevidst, og undtagelsen er en enkelt vært eller et subnet, du kan navngive.

Begge hører til den konfiguration, der ejer forbindelsen. En runtime-regel tilføjet i hånden forsvinder ved næste genopkobling, og fejlen vender tilbage på et tidspunkt, hvor ingen husker workaroundet.

Undtagelser, der overlever geninstallering

Efter ændringen gentages den samme uskyldige anmodning, og de samme tællere ses efter. Den lokale destination bør svare, og den tilsigtede fjerndestination bør stadig vise krypteret trafik.

Disse to kontroller bekræfter, at undtagelsen overlevede, og at beskyttelsen ikke gjorde:

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

Afbryd derefter tunnelen med vilje, og genopkobl den, og gentag begge. En undtagelse, der virker før genopkoblingen og fejler efter, blev anvendt på det forkerte lag, og det er den mest almindelige måde, dette problem vender tilbage på.