IPsec-beleid slikt je lokale verkeer in: zo herken je het

De printer op het bureau stopt met antwoorden zodra de tunnel opkomt, en niets in de tunnelconfiguratie noemt de printer. Wat meestal is gebeurd, is dat een beschermde range zo breed is geschreven dat hij hem omvat, zodat de machine nu verkeer probeert te versleutelen dat op het lokale segment had moeten blijven. Het geïnstalleerde beleid lezen verklaart het onderscheppen; het op de juiste plek vernauwen houdt het externe verkeer beschermd. De tocht van mislukte aanvraag naar passend beleid duurt een paar minuten.

Volg de stroom voordat je een selector wijzigt

Begin bij de mislukte aanvraag en noteer vier waarden: het bronadres dat de machine gebruikt, de exacte bestemming, de route die de kernel kiest en het beleid dat bij dat paar past.

Die vier feiten bepalen of het onderscheppen opzettelijk of toevallig is. Een bestemming die binnen de externe selector valt, wordt volgens ontwerp beschermd, zelfs als het ontwerp verkeerd was. Een bestemming erbuiten die toch wordt onderschept, betekent dat iets anders overeenkomt, en de selector wijzigen helpt dan niet. Beide gevallen komen vaak voor, en één commando onderscheidt ze.

Doe dit voordat je iets bewerkt, want het interessante geval is het lokale subnet dat overlapt met een privé-range die de verbinding beschermt. Bekende prefixen zoals 192.168.0.0/16 komen in veel netwerken voor, en een selector die voor een daarvan is geschreven, kan stilletjes de jouwe dekken.

Drie soorten lokaal die zich anders gedragen

Een bestemming die aan deze host is toegewezen, een bestemming op dezelfde link en een bestemming achter een andere interface zijn drie verschillende gevallen. De kernel behandelt elk anders wanneer hij beslist of verkeer bescherming nodig heeft.

Verkeer dat de gateway zelf genereert is ook niet hetzelfde als verkeer dat van een client is doorgestuurd. Een beleid dat er voor doorgestuurd verkeer correct uitziet, kan de eigen beheersessie van de gateway onderscheppen, en zo verliest een beheerder de toegang terwijl hij de tunnel repareert.

De nuttige gewoonte is het geval hardop te benoemen: komt dit pakket van mij, naar mijn link of door mij heen? Elk antwoord wijst naar een andere plek om te vernauwen. Het geval opschrijven voorkomt ook dat de volgende persoon hetzelfde werk opnieuw doet.

Wanneer de beschermde range een hele privé-ruimte is, kunnen alle drie de gevallen er tegelijk in vallen, en wordt het symptoom een machine die niets bereikt behalve het tunneleindpunt.

Lees het geïnstalleerde beleid, niet het bestand

Configuratiebestanden beschrijven de bedoeling; de kernel houdt de beleidsregels die echt overeenkomen. Toon beide en behandel een verschil als de eerste bevinding.

Deze commando's tonen de gekozen route voor de bestemming en het geïnstalleerde beleid in elke richting:

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

De route vertelt je welke interface het pakket zou gebruiken. De beleidslijst vertelt je of op dat pakket vervolgens een sjabloon wordt toegepast, en de verbindingslijst toont welke selectors de daemon denkt te hebben geïnstalleerd. Als de bestemming in een externe selector voorkomt, heb je het onderscheppen gevonden zonder te gokken.

Vernauw de selector of omzeil de bestemming

Er zijn twee ondersteunde reparaties en ze beantwoorden verschillende vragen. De selector vernauwen zegt dat deze verbinding alleen een kleinere range beschermt, wat klopt als de bredere range een fout was. Een uitzondering toevoegen zegt dat deze specifieke bestemming nooit beschermd mag worden, wat klopt als de beschermde range echt breed is en één bestemming de uitzondering is.

Kies de eerste wanneer je kunt, want een kleinere selector is makkelijker te beredeneren en staat in de verbindingsdefinitie. Kies de tweede wanneer de brede range opzettelijk is en de uitzondering een enkele host of subnet is die je kunt benoemen.

Beide horen in de configuratie die de verbinding bezit. Een handmatig toegevoegde runtimeregel verdwijnt bij de volgende herverbinding, en de fout komt terug op een moment dat niemand de workaround nog herinnert.

Herinstallatiebestendige uitzonderingen

Herhaal na de wijziging dezelfde onschuldige aanvraag en kijk naar dezelfde tellers. De lokale bestemming zou moeten antwoorden, en de bedoelde externe bestemming zou nog steeds versleuteld verkeer moeten tonen.

Deze twee controles bevestigen dat de uitzondering heeft overleefd en de bescherming niet:

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

Verbreek daarna opzettelijk de tunnel en verbind opnieuw, en herhaal beide. Een uitzondering die vóór de herverbinding werkt en erna faalt, is op de verkeerde laag toegepast, en dat is de meest gebruikelijke manier waarop dit probleem terugkomt.