ASA VPN hairpin: encamiñar dous túneles por unha soa interface

Un usuario remoto conéctase ao ASA, pide un equipo detrás dunha sucursal, e o ASA envía esa petición pola mesma interface pola que chegou o usuario. Nada diso require un segundo porto físico. O que si require son catro decisións independentes que a xente adoita fundir nunha: permiso para facer hairpin, un túnel que protexa os enderezos correctos, unha política NAT que conserve a orixe que prometiches e unha política de acceso que autorice o servizo.

Un paquete, dous túneles

Segue o fluxo e a orde das operacións deixa de ser misteriosa. O paquete chega dentro do túnel de acceso remoto, descifrase e convértese nun paquete IP corrente con orixe no conxunto de clientes. Despois o ASA encamínao, compárao coa ACL de cifrado de sitio a sitio, cífrao de novo e envíao pola interface exterior cara á sucursal.

Os enderezos de abaixo son ilustrativos, pero a forma importa: a orixe é o conxunto, non a LAN interna do 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

Diso derivan dúas cousas. O cliente necesita unha ruta para o prefixo da sucursal a través da súa conexión de acceso remoto, o que significa que o split-tunnel ou a lista de rutas empurradas debe incluíla. E a sucursal debe saber como devolver o tráfico a 10.77.0.20 ou ao enderezo que substituíse o teu deseño de NAT.

O permiso de hairpin é global

O comando ao que a xente recorre é same-security-traffic permit intra-interface. Permite que o tráfico entre e saia pola mesma interface, que é exactamente o que necesita este camiño. Tamén é un axuste global: activalo cambia o comportamento doutros fluxos que casualmente atravesan a mesma interface dúas veces.

Por iso pertence a un rexistro de cambios e non a unha sesión de depuración. Pregunta que máis no equipo podería agora tomar un camiño pola mesma interface, e se algo diso debería. Nunha contorna ocupada con redes de convidados ou túneles de socios solapados, a resposta non é automaticamente non. Escribe o motivo xunto ao axuste, porque o seguinte enxeñeiro atopará o comando e non a conversa.

Alcance da protección e NAT son separados

O túnel de sitio a sitio protexe o que seleccione a súa ACL de cifrado. Se esa ACL nomea a subrede interna do ASA como orixe, o conxunto de acceso remoto non queda protexido e o paquete será descartado ou enviado en claro, segundo o comportamento da plataforma co tráfico non coincidente. Engade o conxunto ao fluxo protexido cando o deseño conserve os enderezos do conxunto.

Despois o NAT decide se o enderezo do conxunto sobrevive. O Identity NAT consérvao, e a sucursal ve 10.77.0.20 como orixe. A tradución cambia o contrato: a sucursal agora devolve o tráfico ao enderezo traducido, e a súa propia política ten que aceptalo. A orde das regras decide se a ACL de cifrado coincide antes ou despois da tradución, así que le o fluxo efectivo en vez de supoñer cal gaña.

Non borres as regras PAT xerais de internet para que funcione un só caso de tránsito. Unha excepción dirixida ou unha regra de identidade deliberada son máis fáciles de explicar e de reverter que un burato na política de saída.

O cifrado non é autorización

Un túnel que funciona só demostra que dous extremos coinciden en claves e selectores. Non di nada sobre se este usuario pode alcanzar ese servizo. O filtro VPN ou a política de grupo ligados á conexión de acceso remoto aínda teñen que permitir o destino e o porto da sucursal, e a ACL de interface no camiño exterior segue aplicándose.

Proba a resposta en ambos os sentidos. Unha conexión que ten éxito mentres un servizo veciño debería fallar é máis informativa que un ping correcto, porque mostra que a política é selectiva e non está aberta de par en par. Se a proba que debería ser denegada ten éxito, o culpable non é o túnel, senón a política. Garda ambos os resultados no rexistro de cambios para que a seguinte persoa saiba que comportamento era o previsto.

Hairpin ou unha segunda interface

O tránsito hairpin mantén o deseño pequeno e custa un axuste global. Unha interface separada, ou un túnel baseado en rutas coa súa propia interface virtual, illa o camiño de tránsito e dache política por interface, a cambio de endereitamento e outro mapa de cifrado ou perfil. Ningún é máis correcto; fallan de forma distinta.

Os deseños baseados en rutas son outra disposición, non unha casiña na mesma configuración. Se pasas a un, a discusión sobre a ACL de cifrado baseada en políticas deixa de aplicarse e a táboa de encamiñamento comeza a facer o traballo de selección.

Verifica desde o cliente real

Unha sonda orixinada no ASA ten un enderezo de orixe distinto e non percorrerá o camiño do conxunto á sucursal. Usa packet-tracer para comprobar a quíntupla, e despois abre unha conexión real desde o cliente remoto real, porque o rastrexador simula e non substitúe o encamiñamento nin a política do propio cliente.

Tras un cambio planificado, conéctate a un servizo que debería funcionar, despois a un que debería ser denegado, e despois confirma a ruta de retorno da sucursal. Os exemplos de NAT hairpin para VPN de Cisco manteñen o permiso intra-interface, o NAT e as ACL visiblemente separados, e ese é o modelo mental que paga a pena copiar.