Un usuari remot es connecta a l'ASA, demana un amfitrió darrere d'una sucursal, i l'ASA envia aquesta petició per la mateixa interfície per la qual va arribar l'usuari. Res d'això no requereix un segon port físic. El que sí que requereix són quatre decisions independents que la gent sol ajuntar en una: permís per fer hairpin, un túnel que protegeixi les adreces correctes, una política NAT que conservi l'origen que vas prometre i una política d'accés que autoritzi el servei.

Un paquet, dos túnels

Segueix el flux i l'ordre de les operacions deixa de ser misteriós. El paquet arriba dins del túnel d'accés remot, es desxifra i es converteix en un paquet IP corrent amb origen al conjunt de clients. L'ASA llavors l'encamina, el compara amb l'ACL de criptografia de lloc a lloc, el torna a xifrar i l'envia per la interfície exterior cap a la sucursal.

Les adreces següents són il·lustratives, però la forma és important: l'origen és el conjunt, no la LAN interna de l'ASA.

remote client 10.77.0.20
  -> remote-access tunnel, terminated on ASA outside
  -> decrypted, routed, matched against site-to-site policy
  -> site-to-site tunnel, sent from ASA outside
  -> branch host 10.60.20.10

Se'n deriven dues coses. El client necessita una ruta per al prefix de la sucursal a través de la seva connexió d'accés remot, cosa que vol dir que el split-tunnel o la llista de rutes emeses l'ha d'incloure. I la sucursal ha de saber com retornar el trànsit a 10.77.0.20 o a l'adreça que hagi substituït el teu disseny de NAT.

El permís de hairpin és global

La comanda a la qual la gent recorre és same-security-traffic permit intra-interface. Permet que el trànsit entri i surti per la mateixa interfície, que és exactament el que necessita aquest camí. També és un paràmetre global: activar-lo canvia el comportament d'altres fluxos que passen dues vegades per la mateixa interfície.

Per això pertany a un registre de canvis i no a una sessió de depuració. Pregunta què més de l'equip podria ara agafar un camí per la mateixa interfície, i si alguna cosa ho hauria de fer. En una vora ocupada amb xarxes de convidats o túnels de socis solapats, la resposta no és automàticament no. Escriu el motiu al costat del paràmetre, perquè el proper enginyer trobarà la comanda i no la conversa.

Abast de protecció i NAT són separats

El túnel de lloc a lloc protegeix allò que seleccioni la seva ACL de criptografia. Si aquesta ACL anomena la subxarxa interna de l'ASA com a origen, el conjunt d'accés remot no queda protegit i el paquet o bé es descarta o bé s'envia en clar, segons el comportament de la plataforma amb el trànsit no coincident. Afegeix el conjunt al flux protegit quan el disseny conserva les adreces del conjunt.

Després el NAT decideix si l'adreça del conjunt sobreviu. L'Identity NAT la conserva, i la sucursal veu 10.77.0.20 com a origen. La traducció canvia el contracte: la sucursal ara retorna el trànsit a l'adreça traduïda i la seva pròpia política l'ha d'acceptar. L'ordre de les regles decideix si l'ACL de criptografia coincideix abans o després de la traducció, així que llegeix el flux efectiu en lloc de suposar quina guanya.

No esborris les regles PAT generals d'internet per fer funcionar un sol cas de trànsit. Una exempció dirigida o una regla d'identitat deliberada són més fàcils d'explicar i de revertir que un forat a la política de sortida.

El xifrat no és autorització

Un túnel que funciona només demostra que dos extrems coincideixen en claus i selectors. No diu res sobre si aquest usuari pot arribar a aquell servei. El filtre VPN o la política de grup lligats a la connexió d'accés remot encara han de permetre la destinació i el port de la sucursal, i l'ACL d'interfície del camí exterior encara s'aplica.

Prova la resposta en totes dues direccions. Una connexió que té èxit mentre un servei veí hauria de fallar és més informativa que un ping correcte, perquè mostra que la política és selectiva i no oberta de bat a bat. Si la prova que hauria de ser denegada té èxit, el culpable no és el túnel, sinó la política. Guarda tots dos resultats al registre de canvis perquè la propera persona sàpiga quin comportament era el previst.

Hairpin o una segona interfície

El trànsit hairpin manté el disseny petit i costa un paràmetre global. Una interfície separada, o un túnel basat en rutes amb la seva pròpia interfície virtual, aïlla el camí de trànsit i et dona política per interfície, a canvi d'adreçament i un altre mapa de criptografia o perfil. Cap no és més correcte; fallen de manera diferent.

Els dissenys basats en rutes són una altra disposició, no una casella a la mateixa configuració. Si hi passen, la discussió sobre l'ACL de criptografia basada en polítiques deixa d'aplicar-se i la taula d'encaminament comença a fer la feina de selecció.

Verifica des del client real

Una sonda originada a l'ASA té una adreça d'origen diferent i no exercitarà el camí del conjunt a la sucursal. Fes servir packet-tracer per comprovar la quíntuple, i després obre una connexió real des del client remot autèntic, perquè el traçador simula i no substitueix l'encaminament ni la política del client.

Després d'un canvi planificat, connecta't a un servei que hauria de funcionar, després a un que hauria de ser denegat, i confirma la ruta de retorn de la sucursal. Els Els exemples de NAT hairpin per a VPN de Cisco mantenen el permís intra-interface, el NAT i les ACL visiblement separats, i aquest és el model mental que val la pena copiar.

Articles relacionats