Waarom een IPsec-beveiligingsbeleid geen vermelding in de routetabel is

Ping 10.20.0.5 door de tunnel en er komt niets terug, terwijl de routetabel volhoudt dat dat subnet bereikbaar is. Routing en IPsec beantwoorden verschillende vragen, en slechts één ervan gaat over bereikbaarheid. De forward-lookup kiest een pad, daarna beslist de database met beveiligingsbeleid of dat pad beschermd, met rust gelaten of geweigerd moet worden. Als de twee het oneens zijn, sterft het pakket stilletjes, dus lees ze in die volgorde.

Begin bij de opzoeking, niet bij de tabel

Vraag de kernel wat hij werkelijk zou doen: ip route get 10.20.0.5 toont de gekozen route, de uitgaande interface en het bronadres dat hij zou gebruiken. Een prefix, een beleidsregel, een mark of een voorkeursbron kunnen dat antwoord allemaal veranderen, daarom wint de live opzoeking het van de tabel met het oog lezen.

Test een bestemming binnen het beschermde bereik, niet het gatewayadres. De gateway aan de overkant bereiken bewijst alleen dat er een route bestaat; het zegt niets over het subnet dat je echt nodig hebt. Bevestig daarna dat de interface die de opzoeking koos degene is waarvan je verwacht dat de tunnel die gebruikt.

Laat de selectors aan beide kanten overeenkomen

De beleidsdatabase heeft eigen vermeldingen, en elk daarvan noemt een richting, een bron, een bestemming en een protocol, en zegt dan wat er met overeenkomende pakketten moet gebeuren. Gebruik ip xfrm policy om ze op te sommen; de vlaggen tonen of de actie beschermen, omzeilen of blokkeren is. Een beleid waarvan de selectors breder of smaller zijn dan je testflow komt er niet mee overeen, en het pakket vertrekt onbeschermd. Dat is de storing die je zoekt, geen ontbrekende route.

Vergelijk de werkelijke waarden: bron, bestemming, protocol en poorten. Als de opzoeking het ene adrespaar heeft opgelost terwijl de beleidsvermelding een ander dekt, beschrijven de twee weergaven verschillend verkeer. Voer beide opnieuw uit met dezelfde tuple voordat je een conclusie trekt, anders bewerk je een beleid dat nooit in het pad lag.

Een beleidstreffer is geen geïnstalleerde toestand

Een overeenkomend beleid zegt alleen dat het pakket beschermd moet worden; de kernel heeft nog steeds een beveiligingsassociatie nodig om de bescherming uit te voeren. Som ze op met ip xfrm state, of met swanctl --list-sas wanneer strongSwan onderhandelt, en lees de selectors en tellers van elke vermelding.

Wanneer een beleid overeenkomt en geen associatie dezelfde selectors dekt, wordt het pakket gedropt in plaats van in platte tekst verzonden. Dat is de drop waarnaar je moet zoeken wanneer de tunnel actief is maar één subnet faalt. De tellers zeggen de rest: een associatie die nooit toeneemt werd nooit gekozen, terwijl een die toeneemt en toch in een drop eindigt op de andere kant wijst. Selectors corrigeren en sleutels vernieuwen zijn verschillende reparaties, dus beslis welke je nodig hebt voordat je de configuratie aanraakt.

Wat een routegebaseerde tunnel nog steeds vereist

Een XFRM-interface laat de tunnel lijken op een apparaat waar je naartoe kunt routeren, wat echt nuttig is. Het verwijdert het beleid en de toestand niet die bepalen wat er gebeurt zodra het pakket daar aankomt. De route draagt een volgende hop bij en niets meer.

Als het apparaat bestaat en de route erin wijst terwijl geen associatie bij de inwendige selectors past, wordt het pakket weggegooid, en geen enkele mate van routebewerking levert sleutels of selectors op. Controleer de interface met dezelfde bron en bestemming die je hebt gerouteerd, en vergelijk dat dan met de toestandslijst.

Maak het eigenaarschap duidelijk voordat je iets bewerkt

Een host-firewall voegt een derde beslissing toe die geen van beide databases kent. Een juiste route plus een overeenkomend beleid plus een geïnstalleerde associatie kunnen nog steeds eindigen in een gedropt pakket, en de toepassing meldt alleen de time-out. Bevestig dat de firewall het beschermde verkeer toestaat voordat je IPsec de schuld geeft. Vastleggen op het tunnelapparaat en op de fysieke interface toont aan welke kant van de versleuteling het pakket verdwenen is.

Eigenaarschap van de configuratie bepaalt of je correctie een herstart overleeft. Eén component kan toestand installeren terwijl een andere de routes beheert, en een handmatige bewerking van de tweede wordt overschreven de volgende keer dat de tunnel omhoog komt. Wijzig de eigenaarconfiguratie en lees daarna beide weergaven opnieuw; RFC 4301 houdt de twee databases gescheiden wanneer je de splitsing aan iemand anders moet uitleggen.