Inkommande IPsec-peer som inte matchar någon profil? Kontrollera fyra fält

Din peer rapporterar att tunneln är uppe, din sida visar ingen säkerhetsassociation, och konfigurationsfilen innehåller tydligt ett matchande anslutningsnamn. Alla tre påståendena kan vara sanna samtidigt. En inkommande förhandling matchas mot den körande konfigurationen, utifrån peerens adress, identiteten den presenterar och trafiken den föreslår. En fil på disk som aldrig lästes in, en identitet som inte stämmer med det förväntade värdet, eller ett selektorpar som är förskjutet med ett prefix ger var och en tystnad. Gå igenom de fyra fältgrupperna i den ordning svararen följer.

Börja vid paketet, inte vid filen

Svararen tar emot en IKE-förfrågan, letar efter en definition som kan acceptera denna peer och fortsätter sedan med autentisering och trafikval. Om ingen inläst definition matchar i första steget avslutas förhandlingen innan något användbart fel når användaren.

Därför är ”konfigurationen ser korrekt ut” inget bevis. Frågan är vad den körande tjänsten har läst in och vilken post den valde för detta försök. En statuslista svarar på det med ett enda kommando, medan editorns buffert svarar på en annan fråga. Kontrollera listan innan du ändrar filen igen.

Första fältgruppen: definitionen som faktiskt är inläst

Kontrollera det körande tillståndet med verktyget som äger daemonen: ett statuskommando som listar inlästa anslutningar, inte editorns buffert. Bekräfta att den förväntade posten finns, är aktiverad för det startbeteende du vill ha och lästes in efter din senaste ändring. En sparad fil som inte lästs in igen är den vanligaste orsaken till ”jag fixade det och ingenting ändrades”.

Bekräfta också vilken fil tjänsten läser. Distributioner skiljer sig, och en anslutning som skrivits i fel inkludering ignoreras tyst i stället för att avvisas. Om statuslistan inte visar din post alls, misstänk inkluderingssökvägen före syntaxen.

Andra fältgruppen: ändpunkter är inte identiteter

Adressen som peeren ansluter från och identiteten den autentiserar med är separata fält. Ett värdnamn, ett utmärkande namn, ett nyckel-ID och en adress kan alla tjäna som IKE-identitet beroende på konfigurationen, och de behöver inte alls likna den offentliga adressen.

Ändpunktsmatchning kan också innebära en NAT-vy: adressen som ses på nätet kan skilja sig från adressen som peeren tror sig ha. I libreswans anslutningsmodell är left och right etiketter för de två deltagarna och inte en fast lokal och fjärr ordning, och därför är kopiering av en fungerande konfiguration från en annan plats med utbytta adresser inte en tillförlitlig översättning.

Skriv ned båda sidornas förväntade identitet och den legitimation som validerar den. Om de två raderna inte stämmer överens ger ingen adressjustering en matchning.

Tredje fältgruppen: trafiken som skyddas

Selektorerna beskriver de inre käll- och målområdena, deras adressfamilj och varje protokoll- eller portbegränsning. Ett förslag för en enda värdadress är inte samma begäran som för ett helt subnät, och en svarare konfigurerad för subnätet kan avvisa eller snäva in det.

När de två ändarna inte är överens, jämför det avsedda flödet från båda synvinklarna i stället för att vidga varje selektor så att något ansluter. Fråga varje administratör vilket flöde de tror att de skyddar och jämför sedan de två svaren. Avvikelsen är oftast ett värdprefix på ena sidan och ett subnät på den andra. En tunnel som matchar eftersom den nu skyddar allt är ett annat säkerhetsbeslut, och ett som ingen har godkänt.

Fjärde fältgruppen: du läser en implementering

Libreswan, äldre Openswan och strongSwan har olika administrationsverktyg, olika konfigurationssyntax och olika matchningsordning. Ett fungerande exempel från en säger ingenting exakt om en annans profilvalsprioritet eller felformulering, så verifiera med dokumentationen för daemonen på den här värden.

Korrelera ett försök från början till slut: initiativtagarens källadress, den erbjudna identiteten och de föreslagna selektorerna — mot svararens valsmeddelande och den inlästa post som det namnger. Nollräknare för inkapsling och avkapsling säger bara att de observerade associationerna inte har burit dessa paket; de namnger inte den ändpunkt som avvisade förslaget och bevisar inte att en matchande post fanns i det ögonblicket.

Efter en samordnad rättelse, bekräfta den valda profilen och associationen och testa sedan den faktiskt tillåtna tjänsten och dess svarsväg. En profilmatch möjliggör förhandling, och förhandling är inte den sista åtkomstkontrollen.