Como modelar un fluxo VPN con ASA packet-tracer

Packet-tracer nun ASA responde unha pregunta estreita: permitiríase este paquete, que entra aquí con esta tupla, e a onde iría. Non responde se o extremo afastado recibe algo. O erro habitual é introducir unha tupla IKE exterior cando o que quere probar é a aplicación que viaxa dentro do túnel. Corrixa primeiro a tupla, lea as fases e despois obteña probas reais de todo o que o simulador non pode ver.

O percorrido seguinte supón que ten diante o ACL, a regra NAT e o contexto tunnel-group. Sen eles, a saída describe unha política que non pode comprobar.

Paso 1: escriba o fluxo interior con palabras sinxelas

Describa a aplicación antes de escribir nada. Un host do interior que abre SSH cara a un servidor detrás da pasarela afastada é un fluxo TCP interior cun porto de orixe concreto. Ese é o fluxo que avalían o ACL e o filtro VPN, así que ese é o fluxo que escribe.

Escríbao como unha frase e despois tradúzao campo por campo:

packet-tracer input inside tcp 10.30.0.25 53000 10.40.0.50 22 detailed

Paso 2: escolla a entrada e a dirección

A entrada é a interface pola que chega o paquete, non a que abandona. Para un host LAN que inicia, é a interface inside. Para o paquete de retorno da mesma sesión, é a interface outside, e a tupla investiuse. Escribir o destino como a orixe é a segunda forma máis habitual de obter un ALLOW convincente pero irrelevante.

Os portos tamén teñen dirección. O porto do servizo pertence ao campo de destino nunha solicitude iniciada, e o porto efémero do cliente pertence ao campo de orixe. Un modelo con destino TCP 500 describe unha aplicación TCP que escoita en 500; non se converte nunha proba IKE só porque o número apareza na orde.

Paso 3: lea as fases en orde

Cada fase da saída é unha decisión cun propietario: busca de ruta, ACL, NAT e despois selección de VPN ou túnel. Léaas na orde impresa e detéñase na primeira fase que discrepe do deseño.

NAT atrapa moita xente. Se a orixe traducida cae fóra do crypto ACL que selecciona o tráfico para o túnel, o fluxo pode permitirse e nunca encapsularse. O trazado imprime o enderezo traducido, así que compáreo co tráfico interesante do túnel e non co enderezo orixinal.

Paso 4: comprobe que omisións seleccionou

A forma detailed acepta opcións que saltan comprobacións, e Cisco documenta unha opción bypass-checks que cobre ACL, filtro VPN, uRPF e comprobacións de suplantación IPsec. Un ALLOW obtido con esas omisións di que a ruta e o NAT funcionarían, non que a política admitiría un paquete real. Anote as opcións xunto ao resultado.

Se necesita a resposta de política, executeo sen as omisións. Se illa unha pregunta de encamiñamento, executeo con elas e etiquete o resultado como resposta de encamiñamento.

Paso 5: peche a diferenza co intercambio real

Un permiso simulado detense no ASA. Se a pasarela afastada descifrou o paquete, se o servidor aceptou a conexión e se volveu unha resposta son observacións separadas. Use contadores de extremo ou unha captura estreita nun camiño aprobado.

Algunhas opcións de trace e replay transmiten paquetes ou conservan estado. Siga o comportamento documentado para a súa versión e o seu procedemento de diagnóstico aprobado en lugar de tratar cada variante como unha consulta de só lectura.

O que aínda non lle pode dicir o trazado

Garde catro cousas nunha nota: a tupla, a regra NAT coincidente, o túnel ou a política que debería levar o fluxo e a observación específica da dirección. Sen elas, un enxeñeiro posterior non pode separar unha decisión local de política dun plano de control establecido e dun servizo que funciona. Un primeiro fallo seguido dun éxito tampouco demostra que o túnel tivese que subir entretanto; anote a fase e o cambio de estado.

Comece pola tupla interior, detéñase na primeira fase que contradiga o deseño e só entón busque probas de extremo. O trazado é un oráculo de política, non un acuse de entrega.