IPsec-policy sväljer din lokala trafik: så här ser du det

Skrivaren på skrivbordet slutar svara i samma stund som tunneln kommer upp, och inget i tunnelkonfigurationen nämner skrivaren. Det som oftast har hänt är att ett skyddat intervall skrevs tillräckligt brett för att omfatta den, så maskinen försöker nu kryptera trafik som skulle stanna på det lokala segmentet. Att läsa den installerade policyn förklarar infångningen; att smalna av den på rätt ställe håller fjärrtrafiken skyddad. Vandringen från misslyckad begäran till matchande policy tar några minuter.

Följ flödet innan du ändrar en selektor

Börja vid den misslyckade begäran och skriv ned fyra värden: källadressen som maskinen använder, det exakta målet, rutten som kärnan väljer och policyn som matchar det paret.

Dessa fyra fakta avgör om infångningen är avsiktlig eller oavsiktlig. Ett mål som ligger inom fjärrselektorn skyddas enligt design, även om designen var fel. Ett mål utanför den som ändå fångas upp betyder att något annat matchar, och att ändra selektorn hjälper inte. Båda fallen är vanliga, och ett enda kommando skiljer dem åt.

Gör detta innan du redigerar något, för det intressanta fallet är det lokala subnätet som överlappar ett privat intervall som anslutningen skyddar. Bekanta prefix som 192.168.0.0/16 förekommer i många nätverk, och en selektor skriven för ett av dem kan tyst täcka ditt eget.

Tre slags lokalt som beter sig olika

Ett mål som är tilldelat den här värden, ett mål på samma länk och ett mål bakom ett annat gränssnitt är tre olika fall. Kärnan behandlar var och en olika när den avgör om trafiken behöver skydd.

Trafik som gatewayen själv genererar är inte heller samma sak som trafik vidarebefordrad från en klient. En policy som ser korrekt ut för vidarebefordrad trafik kan fånga gatewayens egen administrationssession, och det är så en administratör förlorar åtkomsten medan han reparerar tunneln.

Den användbara vanan är att namnge fallet högt: kommer det här paketet från mig, till min länk eller genom mig? Varje svar pekar på en annan plats att smalna av. Att skriva ned fallet hindrar också nästa person från att göra om samma arbete.

När det skyddade intervallet är ett helt privat utrymme kan alla tre fallen hamna inuti det samtidigt, och symtomet blir en maskin som inte når något utom tunnelns ändpunkt.

Läs den installerade policyn, inte filen

Konfigurationsfiler beskriver avsikten; kärnan håller de policyer som faktiskt matchar. Visa båda och behandla en avvikelse som det första fyndet.

Dessa kommandon visar den valda rutten till målet och de installerade policyerna i varje riktning:

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

Rutten berättar vilket gränssnitt paketet skulle använda. Policylistan berättar om en mall sedan tillämpas på paketet, och anslutningslistan visar vilka selektorer daemonen tror sig ha installerat. Om målet finns i en fjärrselektor har du hittat infångningen utan att gissa.

Smalna av selektorn eller kringgå målet

Det finns två åtgärder som stöds, och de svarar på olika frågor. Att smalna av selektorn säger att den här anslutningen bara skyddar ett mindre intervall, vilket är rätt när det bredare intervallet var ett misstag. Att lägga till ett kringgående säger att detta specifika mål aldrig får skyddas, vilket är rätt när det skyddade intervallet verkligen är brett och ett mål är undantaget.

Välj den första när du kan, för en mindre selektor är lättare att resonera om och syns i anslutningsdefinitionen. Välj den andra när det breda intervallet är avsiktligt och undantaget är en enda värd eller ett subnät som du kan namnge.

Båda hör hemma i konfigurationen som äger anslutningen. En runtime-regel som lagts till för hand försvinner vid nästa återanslutning, och felet återkommer i ett ögonblick då ingen minns workarounden.

Undantag som överlever ominstallation

Upprepa efter ändringen samma ofarliga begäran och titta på samma räknare. Det lokala målet bör svara, och det avsedda fjärrmålet bör fortfarande visa krypterad trafik.

Dessa två kontroller bekräftar att undantaget överlevde och att skyddet inte gjorde det:

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

Koppla sedan från tunneln med avsikt och anslut igen, och upprepa båda. Ett undantag som fungerar före återanslutningen och misslyckas efter har tillämpats på fel lager, och det är det vanligaste sättet detta problem kommer tillbaka på.