Kan én WAN-grensesnitt betjene både sted-til-sted- og ekstern VPN?

Én offentlig adresse kan betjene en filialtunnel og en pulje med roaming-brukere samtidig. Men den kan ikke betjene én felles adgangsregel. Filialens peer og roaming-brukeren er forskjellige i hvem de hevder å være, hvordan det beviset kontrolleres, hvilke adresser de får, og hvilke prefikser som kan svare dem. Når du først behandler den eksterne adressen som en transportdetalj og ikke som en identitet, blir designet mye enklere.

En rask sunn-fornuft-test: prøv å skrive begge adgangsregistrene før du rører ruteren. Hvis én enkelt matchbetingelse må dekke begge, er policyen allerede tvetydig, og det første symptomet vil se ut som en rute- eller brannmurfeil, mens det egentlig er en identitetsfeil.

To registre før enhver konfigurasjon

Filialregistret er kort og stabilt. Det lister peer-adressen eller sertifikatnavnet, den forhåndsdelte nøkkelen eller sertifikatets trustpoint, de beskyttede subnettene på begge sider, tunnelgrensesnittet og den statiske ruten som sender filialtrafikk inn i den tunnelen. Hvert felt handler om én kjent peer og et fast sett prefikser.

Roaming-registret er bredere og mer personlig. Det lister klientprotokollen og porten, hvordan en bruker eller enhet autentiseres, adressepuljen som deles ut ved tilkobling, ressursene den puljen kan nå, prefiksene for delt tunnel, DNS-serverne som skyves til klienten, og eventuell en andre faktor. Hvert felt svarer på et spørsmål om et ukjent antall brukere og ikke om én gateway.

Den forskjellen i detaljgrad er hele grunnen til at de to rollene skiller lag. En filialprofil kan trygt stole på én nøkkel fordi nøkkelen tilhører én enhet på ett sted. En roamingprofil som stoler på én gruppenøkkel for alle, river ansvarligheten per bruker, og det oppdages vanligvis senere, i en hendelsesgjennomgang og ikke under utrullingen.

Hvor peer-matching og autentisering skiller lag

På IOS XE bærer IKEv2-profilen parameterne som ikke kan forhandles, og betingelsene som brukes til å velge peeren. Det betyr at filialsiden og roamingsiden hver trenger sin egen profil, selv når de terminerer på samme grensesnitt og selv når de deler én kryptografisk PKI. Cisco dokumenterer rollene til profil, autentisering og matching i sin konfigurasjonsveiledning for IKEv2 på IOS XE 17.

Filialprofilen matcher vanligvis en smal identitet: en ekstern adresse, et FQDN eller et sertifikatsubjekt. Noe som match identity remote address 198.51.100.10 255.255.255.255 fester én peer, og authentication remote pre-share med en nøkkel som lagres per sted, er nok. Hold matchingen så spesifikk som peer-inventaret tillater, fordi et overlappende jokertegn høyere oppe i utvalgsrekkefølgen kan trekke filialtrafikk inn i feil profil.

Roamingprofilen kan ikke feste en adresse, så den matcher en gruppe, en key-id eller et sertifikatfelt, og overlater deretter den egentlige brukerkontrollen til AAA eller til autorisasjonspolicyen som er knyttet til profilen. Den delingen betyr noe: peer-autentisering svarer på om klienten får bygge en tunnel, og autorisasjon per bruker svarer på hvilken pulje og hvilke ressurser den får. Bruker du filialnøkkelen som universell innlogging, kaster du det andre svaret bort.

Videresending og oversettelse trenger samme deling

Adgang og nåbarhet er separate problemer. En vellykket IKE- og IPsec-utveksling beviser at partene er enige om nøkler; den oppretter ikke en rute til puljen klienten fikk. Derfor trenger eksterne adgangspuljer en returvei, enten en statisk rute mot tunnelgrensesnittet eller en rutingsprotokoll som injiserer puljeoppsummeringen. Filialprefikser kommer vanligvis gjennom den samme ruteprosessen som betjener resten av stedet.

Oversettelse er der de to rollene oftest kolliderer. Trafikk mellom steder som må beholde sine private adresser, trenger et NAT-unntak avgrenset til de to prefiksene, i begge retninger. Roaming-klienter trenger vanligvis også unntak for trafikken sin i tunnelen, men trafikken deres mot internett går enten utenom tunnelen via delt tunnel eller forlater huben etter NAT. Å unnta alt som kommer fra en tunnel, er den klassiske feilen, fordi det også fjerner oversettelsen fra trafikk som virkelig trenger den.

Hold unntaksreglene like smale som adgangsreglene. Hvis en puljeoppsummering og et filialprefiks overlapper, blir returveien tvetydig lenge før noen pakke slippes, og symptomet viser seg som et sted som av og til mister et subnett, ikke som en ren tunnelfeil.

Aksepttilfeller som avdekker en krysset policy

Bygg fire tilfeller og kjør dem i rekkefølge. En vert i filialen når en ressurs som bare finnes i filialen. En roaming-klient når samme ressurs via puljeadressen sin. En roaming-klient prøver et filialprefiks den ikke skal røre. Filialens peer prøver å få en adresse fra den eksterne adgangspuljen. De to siste er de som fanger en delt profil, fordi de feiler stille i vanlig overvåking.

Bekreft deretter dataplanet og ikke konfigurasjonen. show crypto ikev2 sa og show crypto ipsec sa forteller hvilken profil og hvilke selektorer som bar hver strøm, mens show ip nat translations og tunneltellerne viser om returveien og unntaket faktisk passet. En tracer eller pakkefangst på tunnelgrensesnittet lukker sløyfen.

Skriv den observerte identiteten, puljeadressen og den valgte policyen ved siden av hvert resultat. Kjøringen er ferdig når hvert tilfelle svarer til nøyaktig ett register, og ingen tilfeller trenger et midlertidig unntak for å bestå.