IPsec-verkeersselectors: wat ze wel en niet dekken

Verkeersselectors benoemen het interne verkeer dat een IPsec-afspraak beschermt, en het paar wordt onderhandeld in plaats van aangenomen. Twee eindpunten kunnen elkaar perfect authenticeren en het toch oneens zijn over welke pakketten binnen de tunnel horen. Dat meningsverschil is onzichtbaar in de verbindingsstatus, die meestal een gezonde tunnel meldt. De selectors van beide kanten lezen en dan één bestemming volgen vindt het sneller dan welke beleidsbewerking dan ook.

Lees ze van beide kanten

Elk eindpunt beschrijft zijn eigen kant als lokaal en de andere kant als extern. Hetzelfde paar prefixen verschijnt daardoor omgewisseld in de twee configuraties, en dat is juist en niet tegenstrijdig. Het perspectief omdraaien is het eerste dat je moet doen wanneer een werkende afspraak op papier verkeerd lijkt. Twee bestanden naast elkaar vergelijken zonder ze om te wisselen levert een mismatch op die niet bestaat.

De waarden zijn niet altijd losse subnetten. IKEv2-selectors kunnen adresbereiken, protocolnummers en poortbereiken dragen, en zo beschermt een beleid één dienst in plaats van een heel netwerk. Een selector die smaller is dan het bedoelde verkeer levert een tunnel op die sommige bestemmingen draagt en andere stilzwijgend uitsluit.

Schrijf beide kanten in één tabel voordat je iets verandert. De oefening beslecht de vraag meestal zonder een configuratiebestand aan te raken.

Vernauwen is de beslissing van de responder

Een initiator stelt voor, en de responder mag alleen een subset accepteren. IKEv2 staat de responder toe de aangeboden verkeersselectors te vernauwen, en het vernauwde resultaat is wat werkelijk wordt geïnstalleerd. Het lezen van de configuratie van de initiator beschrijft dus een aanbod, niet de afspraak.

Daarom kan een subnet dat aan de client is toegevoegd een werkende tunnel opleveren die de nieuwe bestemming toch weigert. De server vernauwde het aanbod tot wat zijn beleid toestaat, terwijl het bestand van de client nog het bredere bereik vermeldt. Alleen de onderhandelde toestand toont de waarheid: op Linux melden ip xfrm policy en de child SA-lijst in de IKEv2-documentatie van strongSwan wat is geïnstalleerd en niet wat is aangevraagd. Als de twee van mening verschillen, is het beleid van de responder degene die moet veranderen.

Een geweigerd aanbod is een ander symptoom dan een vernauwd aanbod. Weigering verschijnt in het onderhandelingslog en laat helemaal geen child-associatie achter.

Volg één bestemming van begin tot eind

Kies een echte bestemming plus het bronadres dat de client daarvoor zou gebruiken, en volg dat paar dan door drie onafhankelijke beslissingen. De route kiest een pad, de selector beslist of dat pad beschermd is, en de firewall beslist of het pakket is toegestaan. Elk kan op zichzelf falen, en een brede selector repareert geen van de andere.

ip route get 10.20.30.41
ip xfrm policy list
swanctl --list-sas

De routequery noemt de interface en het bronadres dat het pakket zou dragen. De beleidslijst toont of er een passend tunnelbeleid voor dat paar bestaat, inclusief de richting en het niveau. De SA-lijst toont de onderhandelde child-selectors samen met tellers, dus een child-associatie met nul pakketten na een verkeerspoging is de signatuur van selectors die uitsluiten wat wordt verzonden. Drie opdrachten, drie verschillende antwoorden, en slechts één ervan verklaart een stille drop.

Als de child-tellers bewegen terwijl de toepassing nog steeds faalt, zit het probleem voorbij de tunnel. Dat verplaatst het onderzoek naar de listener of firewall van de externe host en niet naar de selectors.

Houd de twee doelen gescheiden

Een kantoorsubnet beschermen en al het browsen via een externe uitgang sturen zijn verschillende eisen met verschillende selectors. Een profiel dat voor het ene is gebouwd past zelden bij het andere, en ze mengen levert ofwel een lek ofwel een gebroken splitsing op. Het beschermde bereik verbreden betekent beide eindpunten en hun doorstuurbeleid wijzigen, omdat een eenzijdige wijziging een geweigerd aanbod wordt. Dat is de meest voorkomende manier waarop een werkende tunnel na een kleine bewerking ophoudt te werken.

Selectors beschrijven cryptografische dekking, routes kiezen paden, en toepassingen dwingen hun eigen toestemmingen af. Een tunnel die alles dekt, kan nog steeds geen dienst bereiken die aan loopback is gebonden, en een route de tunnel in heeft nog steeds een selector nodig die de bestemming omvat. Controleer alle drie tegen hetzelfde testverzoek, en de mismatch noemt zichzelf.