Kan eitt WAN-grensesnitt tene både stad-til-stad- og ekstern VPN?

Éi offentleg adresse kan tene ein filialtunnel og eit basseng med roaming-brukarar samstundes. Men ho kan ikkje tene éi felles tilgangsregel. Peeren til filialen og roaming-brukaren er ulike i kven dei påstår at dei er, korleis det provet blir kontrollert, kva adresser dei får, og kva prefiks som kan svare dei. Når du først behandlar den eksterne adressa som ein transportdetalj og ikkje som ein identitet, blir designet mykje enklare.

Ein rask sunn-fornuft-test: prøv å skrive båe tilgangsregistra før du rører rutaren. Om eitt einaste matchvilkår må dekkje båe, er policyen alt tvitydig, og det første symptomet vil sjå ut som ein rute- eller brannmurfeil, medan det eigentleg er ein identitetsfeil.

To register før kvar konfigurasjon

Filialregistret er kort og stabilt. Det listar peer-adressa eller sertifikatnamnet, den førehandsdelte nøkkelen eller trustpointet til sertifikatet, dei verna subnetta på båe sider, tunnelgrensesnittet og den statiske ruta som sender filialtrafikk inn i den tunnelen. Kvart felt gjeld éin kjend peer og eit fast sett prefiks.

Roaming-registret er breiare og meir personleg. Det listar klientprotokollen og porten, korleis ein brukar eller eining autentiserer seg, adressebassenget som blir delt ut ved tilkopling, ressursane det bassenget kan nå, prefiksa for delt tunnel, DNS-tenarane som blir dytta til klienten, og ein eventuell andre faktor. Kvart felt svarar på eit spørsmål om eit ukjent tal brukarar og ikkje om éin gateway.

Den skilnaden i detaljgrad er heile grunnen til at dei to rollene skil lag. Ein filialprofil kan trygt stole på éin nøkkel fordi nøkkelen høyrer til éi eining på éin stad. Ein roamingprofil som stolar på éin gruppenøkkel for alle, riv ansvaret per brukar, og det blir vanlegvis oppdaga seinare, i ein hendingsgjennomgang og ikkje under utrullinga.

Kvar peer-matching og autentisering skil lag

På IOS XE ber IKEv2-profilen parametrane som ikkje kan forhandlast, og vilkåra som blir brukte til å velje peeren. Det tyder at filialsida og roamingsida kvar treng sin eigen profil, sjølv når dei terminerer på same grensesnitt og sjølv når dei deler éin kryptografisk PKI. Cisco dokumenterer rollene til profil, autentisering og matching i si konfigurasjonsrettleiing for IKEv2 på IOS XE 17.

Filialprofilen matchar vanlegvis ein smal identitet: ei ekstern adresse, eit FQDN eller eit sertifikatsubjekt. Noko som match identity remote address 198.51.100.10 255.255.255.255 festar éin peer, og authentication remote pre-share med ein nøkkel som blir lagra per stad, er nok. Hald matchinga så spesifikk som peer-inventaret tillèt, fordi eit overlappande jokerteikn høgare oppe i utvalsrekkjefølgja kan trekkje filialtrafikk inn i feil profil.

Roamingprofilen kan ikkje feste ei adresse, så han matchar ei gruppe, ein key-id eller eit sertifikatfelt, og overlèt deretter den eigentlege brukarkontrollen til AAA eller til autorisasjonspolicyen som er knytt til profilen. Den delinga betyr noko: peer-autentisering svarar på om klienten får byggje ein tunnel, og autorisasjon per brukar svarar på kva basseng og kva ressursar han får. Brukar du filialnøkkelen som universell innlogging, kastar du det andre svaret bort.

Vidaresending og omsetjing treng same deling

Tilgang og nåbarheit er separate problem. Ein vellukka IKE- og IPsec-utveksling beviser at partane er samde om nøklar; ho opnar ikkje ei rute til bassenget klienten fekk. Derfor treng eksterne tilgangsbasseng ein returveg, anten ei statisk rute mot tunnelgrensesnittet eller ein rutingsprotokoll som injiserer bassengsamandraget. Filialprefiks kjem vanlegvis gjennom den same ruteprosessen som tener resten av staden.

Omsetjing er der dei to rollene oftast kolliderer. Trafikk mellom stader som må halde på dei private adressene sine, treng eit NAT-unntak avgrensa til dei to prefiksa, i båe retningar. Roamingklientar treng vanlegvis også unntak for trafikken sin i tunnelen, men trafikken deira mot internett går anten utanom tunnelen via delt tunnel eller forlèt huben etter NAT. Å unnta alt som kjem frå ein tunnel, er den klassiske feilen, fordi det også fjernar omsetjinga frå trafikk som verkeleg treng henne.

Hald unntaksreglane like smale som tilgangsreglane. Om eit bassengsamandrag og eit filialprefiks overlappar, blir returvegen tvitydig lenge før nokon pakke blir sleppt, og symptomet viser seg som ein stad som av og til mistar eit subnett, ikkje som ein rein tunnelfeil.

Aksepttilfelle som avdekkjer ein krossa policy

Bygg fire tilfelle og køyr dei i rekkjefølgje. Ein vert i filialen når ein ressurs som berre finst i filialen. Ein roamingklient når same ressurs via bassengadressa si. Ein roamingklient prøver eit filialprefiks han ikkje skal røre. Peeren til filialen prøver å få ei adresse frå det eksterne tilgangsbassenget. Dei to siste er dei som fangar ein delt profil, fordi dei feilar stille i vanleg overvaking.

Stadfest deretter dataplanet og ikkje konfigurasjonen. show crypto ikev2 sa og show crypto ipsec sa fortel kva profil og kva selektorar som bar kvar straum, medan show ip nat translations og tunnelteljarane viser om returvegen og unntaket faktisk passa. Ein tracer eller pakkefangst på tunnelgrensesnittet lukkar sløyfa.

Skriv den observerte identiteten, bassengadressa og den valde policyen ved sida av kvar resultat. Køyringa er ferdig når kvart tilfelle svarar til nøyaktig eitt register, og ingen tilfelle treng eit mellombels unntak for å bestå.