Kan ett enda WAN-gränssnitt betjäna både plats-till-plats- och fjärr-VPN?

En enda offentlig adress kan betjäna en filialtunnel och en pool med roaminganvändare samtidigt. Men den kan inte betjäna en enda gemensam åtkomstregel. Filialens peer och roaminganvändaren skiljer sig i vem de påstår sig vara, hur det beviset kontrolleras, vilka adresser de får och vilka prefix som får svara dem. När du väl behandlar den externa adressen som en transportdetalj och inte som en identitet blir designen mycket enklare.

Ett snabbt sunt-förnuft-test: försök skriva båda åtkomstposterna innan du rör routern. Om ett enda matchningsvillkor måste täcka båda är policyn redan tvetydig, och det första symptomet kommer att se ut som ett routing- eller brandtvärsfel, fast det egentligen är ett identitetsfel.

Två poster före varje konfiguration

Filialposten är kort och stabil. Den listar peer-adressen eller certifikatnamnet, den fördelade nyckeln eller certifikatets trustpoint, de skyddade subnäten på båda sidor, tunnelgränssnittet och den statiska rutten som skickar filialtrafik in i den tunneln. Varje fält handlar om en känd peer och en fast uppsättning prefix.

Roamingposten är bredare och mer personlig. Den listar klientprotokollet och porten, hur en användare eller enhet autentiserar sig, adresspoolen som delas ut vid anslutning, de resurser som poolen får nå, prefixen för delad tunnel, DNS-servrarna som skjuts till klienten och en eventuell andra faktor. Varje fält svarar på en fråga om ett okänt antal användare och inte om en enda gateway.

Den skillnaden i detaljgrad är hela skälet till att de två rollerna skiljs åt. En filialprofil kan tryggt lita på en enda nyckel eftersom nyckeln tillhör en enda enhet på en enda plats. En roamingprofil som litar på en enda gruppnyckel för alla raseras ansvarigheten per användare, och det upptäcks oftast senare, i en incidentgenomgång och inte vid utrullningen.

Var peer-matchning och autentisering skiljs åt

På IOS XE bär IKEv2-profilen de parametrar som inte kan förhandlas och de villkor som används för att välja peer. Det betyder att filialsidan och roamingsidan var och en behöver sin egen profil, även när de terminerar på samma gränssnitt och även när de delar en enda kryptografisk PKI. Cisco dokumenterar rollerna för profil, autentisering och matchning i sin konfigurationsguide för IKEv2 på IOS XE 17.

Filialprofilen matchar vanligtvis en smal identitet: en fjärradress, ett FQDN eller ett certifikatsubjekt. Något som match identity remote address 198.51.100.10 255.255.255.255 fäster en peer, och authentication remote pre-share med en nyckel som lagras per plats räcker. Håll matchningen så specifik som peer-inventariet tillåter, eftersom ett överlappande jokertecken högre upp i urvalsordningen kan dra filialtrafik in i fel profil.

Roamingprofilen kan inte fästa en adress, så den matchar en grupp, ett key-id eller ett certifikatfält och lämnar sedan den egentliga användarkontrollen till AAA eller till den auktorisationspolicy som hänger på profilen. Den uppdelningen spelar roll: peer-autentisering svarar på om klienten får bygga en tunnel, och auktorisering per användare svarar på vilken pool och vilka resurser den får. Att använda filialnyckeln som universell inloggning kastar bort det andra svaret.

Vidarebefordran och översättning behöver samma uppdelning

Åtkomst och nåbarhet är separata problem. Ett lyckat IKE- och IPsec-utbyte bevisar att parterna är överens om nycklar; det skapar ingen rutt till poolen som klienten fick. Därför behöver fjärråtkomstpooler en returväg, antingen en statisk rutt mot tunnelgränssnittet eller ett routingprotokoll som injicerar poolsammanfattningen. Filialprefix kommer vanligtvis via samma routingprocess som betjänar resten av platsen.

Översättning är där de två rollerna oftast krockar. Trafik mellan platser som måste behålla sina privata adresser behöver ett NAT-undantag begränsat till de två prefixen, i båda riktningarna. Roamingklienter behöver oftast också undantag för sin trafik i tunneln, men deras internettrafik går antingen förbi tunneln via delad tunnel eller lämnar hubben efter NAT. Att undanta allt som kommer från en tunnel är det klassiska misstaget, eftersom det också tar bort översättningen från trafik som verkligen behöver den.

Håll undantagsreglerna lika smala som åtkomstreglerna. Om en poolsammanfattning och ett filialprefix överlappar blir returvägen tvetydig långt innan något paket släpps, och symptomet visar sig som en plats som då och då tappar ett subnät och inte som ett rent tunnelfel.

Acceptansfall som avslöjar en korsad policy

Bygg fyra fall och kör dem i ordning. En värd i filialen når en resurs som bara finns i filialen. En roamingklient når samma resurs via sin pooladress. En roamingklient försöker med ett filialprefix som den inte får röra. Filialens peer försöker få en adress från fjärråtkomstpoolen. De två sista är de som fångar en delad profil, eftersom de misslyckas tyst i vanlig övervakning.

Bekräfta sedan dataplanet och inte konfigurationen. show crypto ikev2 sa och show crypto ipsec sa säger vilken profil och vilka selektorer som bar varje flöde, medan show ip nat translations och tunnelräknarna visar om returvägen och undantaget faktiskt stämde. En tracer eller paketfångst på tunnelgränssnittet sluter slingan.

Skriv den observerade identiteten, pooladressen och den valda policyn bredvid varje resultat. Körningen är klar när varje fall motsvarar exakt en post och inget fall behöver ett tillfälligt undantag för att passera.