Pot una sola interfície WAN servir la VPN entre seus i l’accés remot?

Una sola adreça pública pot servir alhora un túnel de branca i un pool d’usuaris en itinerància. Però no pot servir una sola regla d’admissió compartida. El parell de la branca i l’usuari en itinerància difereixen en qui demostren que són, com es comprova aquesta prova, quines adreces reben i quins prefixos els poden respondre. Quan tracteu l’adreça exterior com un detall de transport i no com una identitat, el disseny es torna molt més senzill.

Una prova ràpida de seny: intenteu escriure tots dos registres d’admissió abans de tocar el router. Si una sola condició d’emparellament ha de cobrir tots dos, la política ja és ambigua, i el primer símptoma semblarà una fallada d’encaminament o de tallafocs quan en realitat és una fallada d’identitat.

Dos registres abans de qualsevol configuració

El registre de la branca és curt i estable. Llista l’adreça del parell o el nom del certificat, la clau prèviament compartida o el trustpoint del certificat, les subxarxes protegides a banda i banda, la interfície del túnel i la ruta estàtica que envia el trànsit cap a la branca dins d’aquest túnel. Cada camp tracta d’un parell conegut i d’un conjunt fix de prefixos.

El registre de l’itinerància és més ampli i més personal. Llista el protocol i el port del client, com s’autentica un usuari o un dispositiu, el pool d’adreces que es lliura en connectar, els recursos que aquest pool pot abastar, els prefixos del túnel dividit, els servidors DNS que s’empenyen al client i qualsevol segon factor. Cada camp respon una pregunta sobre un nombre desconegut d’usuaris i no sobre una sola passarel·la.

Aquesta diferència de granularitat és tot el motiu pel qual els dos papers divergeixen. Un perfil de branca pot confiar sense perill en una sola clau perquè la clau pertany a un sol dispositiu en un sol lloc. Un perfil d’itinerància que confia en una sola clau de grup per a tothom enfonsa la responsabilitat per usuari, cosa que normalment es descobreix més tard, durant la revisió d’un incident i no durant el desplegament.

On divergeixen l’emparellament de parells i l’autenticació

A IOS XE el perfil IKEv2 porta els paràmetres que no es poden negociar i les condicions que serveixen per seleccionar el parell. Això vol dir que el costat de la branca i el costat de l’itinerància necessiten cadascun el seu perfil, fins i tot quan acaben a la mateixa interfície i fins i tot quan comparteixen una mateixa PKI criptogràfica. Cisco documenta els papers del perfil, l’autenticació i l’emparellament a la seva guia de configuració d’IKEv2 per a IOS XE 17.

El perfil de la branca normalment emparella una identitat estreta: una adreça remota, un FQDN o un subjecte de certificat. Una cosa com match identity remote address 198.51.100.10 255.255.255.255 fixa un sol parell, i authentication remote pre-share amb una clau emmagatzemada per lloc n’hi ha prou. Manteniu l’emparellament tan específic com permeti l’inventari de parells, perquè un comodí que se superposi més amunt en l’ordre de selecció pot arrossegar el trànsit de la branca cap al perfil equivocat.

El perfil d’itinerància no pot fixar una adreça, així que s’emparella amb un grup, un key-id o un camp del certificat, i després passa la comprovació real de l’usuari a AAA o a la política d’autorització lligada al perfil. Aquesta separació importa: l’autenticació del parell respon si el client pot construir un túnel, i l’autorització per usuari respon quin pool i quins recursos obté. Fer servir la clau de la branca com a inici de sessió universal llença la segona resposta.

El reenviament i la traducció necessiten la mateixa separació

L’admissió i l’abast són problemes separats. Un intercanvi reeixit d’IKE i IPsec demostra que les parts coincideixen en les claus; no crea cap ruta cap al pool que el client ha rebut. Per tant, els pools d’accés remot necessiten un camí de retorn, ja sigui una ruta estàtica apuntant a la interfície del túnel o un protocol d’encaminament que injecti el resum del pool. Els prefixos de la branca solen arribar pel mateix procés d’encaminament que serveix la resta del lloc.

La traducció és on els dos papers xoquen més sovint. El trànsit entre llocs que ha de conservar les seves adreces privades necessita una exempció de NAT limitada a aquests dos prefixos, en tots dos sentits. Els clients en itinerància també solen necessitar l’exempció del trànsit que porten pel túnel, però el seu trànsit cap a internet o bé evita el túnel amb el túnel dividit o bé surt al concentrador després del NAT. Eximir tot el que arriba d’un túnel és l’error clàssic, perquè també treu la traducció a trànsit que de veritat la necessita.

Manteniu les regles d’exempció tan estretes com les regles d’admissió. Si un resum de pool i un prefix de branca se superposen, el camí de retorn es torna ambigu molt abans que es descarti cap paquet, i el símptoma apareix com un lloc que perd una subxarxa de tant en tant i no com una fallada neta del túnel.

Casos d’acceptació que exposen una política creuada

Construïu quatre casos i executeu-los per ordre. Un equip de la branca arriba a un recurs només de la branca. Un client en itinerància arriba al mateix recurs a través de l’adreça del seu pool. Un client en itinerància intenta un prefix de la branca que no hauria de tocar. Un parell de la branca intenta obtenir una adreça del pool d’accés remot. Els dos últims són els que atrapen un perfil compartit, perquè fallen en silenci en la monitorització normal.

Després confirmeu el pla de dades i no la configuració. show crypto ikev2 sa i show crypto ipsec sa us diuen quin perfil i quins selectors han portat cada flux, mentre que show ip nat translations i els comptadors del túnel mostren si el camí de retorn i l’exempció han coincidit de veritat. Un tracer o una captura de paquets a la interfície del túnel tanca el bucle.

Escriviu la identitat observada, l’adreça del pool i la política seleccionada al costat de cada resultat. La tanda s’acaba quan cada cas correspon exactament a un registre i cap cas no necessita una excepció temporal per passar.