Inkomende IPsec-peer past bij geen enkel profiel? Controleer vier velden

Uw peer meldt dat de tunnel omhoog is, uw kant toont geen beveiligingsassociatie, en het configuratiebestand bevat duidelijk een passende verbindingsnaam. Alle drie uitspraken kunnen tegelijk waar zijn. Een inkomende onderhandeling wordt vergeleken met de draaiende configuratie, op basis van het adres van de peer, de identiteit die deze presenteert en het verkeer dat deze voorstelt. Een bestand op schijf dat nooit is geladen, een identiteit die niet overeenkomt met de verwachte waarde, of een selectorpaar dat één prefix mis zit — elk daarvan levert stilte op. Doorloop de vier veldgroepen in de volgorde die de responder volgt.

Begin bij het pakket, niet bij het bestand

De responder ontvangt een IKE-verzoek, zoekt een definitie die deze peer kan accepteren en gaat daarna verder met authenticatie en verkeersselectie. Als in de eerste stap geen geladen definitie past, eindigt de onderhandeling voordat een bruikbare fout de gebruiker bereikt.

Daarom is „de configuratie ziet er goed uit“ geen bewijs. De vraag is wat de draaiende dienst heeft geladen en welke vermelding deze voor deze poging heeft gekozen. Een statuslijst beantwoordt dat met één opdracht, terwijl de buffer van de editor een andere vraag beantwoordt. Controleer de lijst voordat u het bestand opnieuw wijzigt.

Eerste veldgroep: de definitie die werkelijk is geladen

Controleer de draaiende toestand met het gereedschap dat de daemon bezit: een statusopdracht die geladen verbindingen opsomt, niet de buffer van de editor. Bevestig dat de vermelding die u verwacht aanwezig is, is ingeschakeld voor het opstartgedrag dat u bedoelt, en is geladen na uw laatste bewerking. Een opgeslagen bestand dat niet opnieuw is geladen is de meest voorkomende oorzaak van „ik heb het gerepareerd en er is niets veranderd“.

Bevestig ook welk bestand de dienst leest. Distributies verschillen, en een verbinding die in de verkeerde include is geschreven wordt stil genegeerd in plaats van geweigerd. Als de statuslijst uw vermelding helemaal niet toont, verdenk dan het includepad voordat u de syntaxis verdenkt.

Tweede veldgroep: eindpunten zijn geen identiteiten

Het adres waarvandaan de peer verbinding maakt en de identiteit waarmee deze zich authenticeert zijn aparte velden. Een hostnaam, een onderscheiden naam, een sleutel-ID en een adres kunnen allemaal als IKE-identiteit dienen, afhankelijk van de configuratie, en ze hoeven helemaal niet op het openbare adres te lijken.

Het matchen van eindpunten kan ook een NAT-beeld omvatten: het adres dat op het netwerk te zien is kan verschillen van het adres dat de peer denkt te hebben. In het verbindingsmodel van libreswan zijn left en right labels voor de twee deelnemers en geen vaste lokale en externe volgorde, en daarom is het kopiëren van een werkende configuratie van een andere locatie met verwisselde adressen geen betrouwbare vertaling.

Noteer de verwachte identiteit van beide kanten en het bewijsstuk dat deze valideert. Als die twee regels niet overeenkomen, levert geen enkele adresaanpassing een match op.

Derde veldgroep: het verkeer dat wordt beschermd

Selectors beschrijven de interne bron- en bestemmingsbereiken, hun adresfamilie en elke protocol- of poortbeperking. Een voorstel voor één hostadres is niet dezelfde aanvraag als voor een heel subnet, en een responder die voor het subnet is geconfigureerd kan het weigeren of vernauwen.

Als de twee uiteinden het niet eens zijn, vergelijk dan de bedoelde stroom vanuit beide gezichtspunten in plaats van elke selector te verbreden zodat er iets verbindt. Vraag elke beheerder welke stroom hij denkt te beschermen en vergelijk dan de twee antwoorden. De afwijking is meestal een hostprefix aan de ene kant en een subnet aan de andere. Een tunnel die past omdat hij nu alles beschermt is een andere beveiligingsbeslissing, en een die niemand heeft goedgekeurd.

Vierde veldgroep: u leest één implementatie

Libreswan, het oudere Openswan en strongSwan hebben verschillende beheergereedschappen, verschillende configuratiesyntaxis en verschillende matchvolgorde. Een werkend voorbeeld van het ene zegt niets precies over de profielkeuzeprioriteit of de foutformulering van het andere, dus verifieer met de documentatie voor de daemon op deze host.

Correleer één poging van begin tot eind: het bronadres van de initiator, de aangeboden identiteit en de voorgestelde selectors — tegen het keuzebricht van de responder en de geladen vermelding die het noemt. Nultellers voor inkapseling en ontkapseling zeggen alleen dat de waargenomen associaties die pakketten niet hebben gedragen; ze noemen niet het eindpunt dat het voorstel verwierp en bewijzen niet dat er op dat moment een passende vermelding bestond.

Bevestig na een gecoördineerde correctie het gekozen profiel en de associatie, en test daarna de werkelijk toegestane dienst en het antwoordpad ervan. Een profielmatch maakt onderhandeling mogelijk, en onderhandeling is niet de laatste toegangscontrole.