Kan én WAN-grænseflade betjene både sted-til-sted- og fjern-VPN?

Én offentlig adresse kan betjene en gren-tunnel og en pulje af roaming-brugere på samme tid. Den kan ikke betjene én fælles adgangsregel. Grenens peer og roaming-brugeren er forskellige i hvem de beviser at de er, hvordan det bevis kontrolleres, hvilke adresser de får, og hvilke præfikser der må svare dem. Når du først behandler den eksterne adresse som en transportdetalje og ikke som en identitet, bliver designet meget enklere.

En hurtig fornuftstest: prøv at skrive begge adgangsregistre, før du rører routeren. Hvis én enkelt matchbetingelse skal dække begge, er politikken allerede tvetydig, og det første symptom vil ligne en rute- eller firewallfejl, selvom det i virkeligheden er en identitetsfejl.

To registre før enhver konfiguration

Grenregistret er kort og stabilt. Det angiver peer-adressen eller certifikatnavnet, den foruddelte nøgle eller certifikatets trustpoint, de beskyttede subnets på begge sider, tunnelgrænsefladen og den statiske rute, der sender grenens trafik ind i tunnelen. Hvert felt handler om én kendt peer og et fast sæt præfikser.

Roaming-registret er bredere og mere personligt. Det angiver klientprotokol og port, hvordan en bruger eller enhed godkendes, den adressepulje der udleveres ved forbindelse, de ressourcer puljen må nå, præfikser til split-tunnel, DNS-servere der skubbes til klienten, og en eventuel anden faktor. Hvert felt besvarer et spørgsmål om et ukendt antal brugere frem for om én gateway.

Den forskel i detaljegrad er hele grunden til, at de to roller skilles. En grenprofil kan trygt stole på én nøgle, fordi nøglen tilhører én enhed på ét sted. En roamingprofil, der stoler på én gruppenøgle for alle, fjerner ansvarligheden for hver bruger, og det opdages som regel senere, under en hændelsesgennemgang frem for under udrulningen.

Hvor peer-matchning og godkendelse skilles

På IOS XE bærer IKEv2-profilen de parametre, der ikke kan forhandles, og de betingelser, der bruges til at vælge peeren. Det betyder, at gren-siden og roaming-siden hver især har brug for deres egen profil, selv når de terminerer på samme grænseflade, og selv når de deler en kryptografisk PKI. Cisco beskriver profil-, godkendelses- og matchningsrollerne i deres konfigurationsvejledning til IKEv2 på IOS XE 17.

Grenprofilen matcher normalt en snæver identitet: en fjernadresse, et FQDN eller et certifikatsubjekt. Noget som match identity remote address 198.51.100.10 255.255.255.255 låser én peer fast, og authentication remote pre-share med en nøgle, der gemmes for hvert sted, er nok. Hold matchningen så specifik, som peer-inventaret tillader, fordi et overlappende wildcard højere oppe i udvalgsrækkefølgen kan trække grenens trafik ind i den forkerte profil.

Roamingprofilen kan ikke låse en adresse fast, så den matcher en gruppe, et key-id eller et certifikatfelt og overlader derefter den egentlige brugerkontrol til AAA eller til den autorisationspolitik, der er knyttet til profilen. Den adskillelse betyder noget: peer-godkendelse svarer på, om klienten må bygge en tunnel, og autorisation for hver bruger svarer på, hvilken pulje og hvilke ressourcer den får. Bruger du grenens nøgle som universelt login, smider du det andet svar væk.

Videresendelse og oversættelse har brug for samme opdeling

Adgang og nåbarhed er separate problemer. En vellykket IKE- og IPsec-udveksling beviser, at parterne er enige om nøgler; den opretter ikke en rute til den pulje, klienten fik. Fjernadgangspuljer har derfor brug for en returvej, enten en statisk rute mod tunnelgrænsefladen eller en routingprotokol, der injicerer puljens oversigt. Grenens præfikser kommer normalt ad samme routingproces, som betjener resten af stedet.

Oversættelse er der, hvor de to roller oftest støder sammen. Trafik mellem steder, der skal beholde sine private adresser, har brug for en NAT-fritagelse afgrænset til de to præfikser, i begge retninger. Roaming-klienter har normalt også brug for fritagelse af deres trafik i tunnelen, men deres internettrafik går enten uden om tunnelen via split-tunnel eller forlader hubben efter NAT. At fritage alt, der kommer fra en tunnel, er den klassiske fejl, fordi det også fjerner oversættelsen fra trafik, der virkelig har brug for den.

Hold fritagelsesreglerne lige så snævre som adgangsreglerne. Hvis en puljeoversigt og et grenpræfiks overlapper, bliver returvejen tvetydig længe før, der droppes en pakke, og symptomet viser sig som et sted, der af og til mister et subnet, frem for som en ren tunnelfejl.

Accepttest, der afslører en krydset politik

Byg fire tilfælde og kør dem i rækkefølge. En vært i grenen når en ressource, der kun findes i grenen. En roaming-klient når samme ressource via sin puljeadresse. En roaming-klient forsøger et grenpræfiks, den ikke må røre. En gren-peer forsøger at få en adresse fra fjernadgangspuljen. De sidste to er dem, der fanger en delt profil, fordi de fejler lydløst i normal overvågning.

Bekræft derefter dataplanet frem for konfigurationen. show crypto ikev2 sa og show crypto ipsec sa fortæller, hvilken profil og hvilke selektorer der bar hver strøm, mens show ip nat translations og tunnel-tællerne viser, om returvejen og fritagelsen faktisk passede. En tracer eller pakkeoptagelse på tunnelgrænsefladen lukker kredsen.

Skriv den observerede identitet, puljeadressen og den valgte politik ved siden af hvert resultat. Kørslen er færdig, når hvert tilfælde svarer til præcis ét register, og ingen tilfælde har brug for en midlertidig undtagelse for at bestå.