Kiel modeli VPN-fluon per ASA packet-tracer

Packet-tracer sur ASA respondas al mallarĝa demando: ĉu ĉi tiu paketo, eniranta ĉi tie kun ĉi tiu opo, estus permesita, kaj kien ĝi irus. Ĝi ne respondas, ĉu la fora fino ricevas ion. La kutima eraro estas enigi eksteran IKE-opon, kiam tio, kion vi volas testi, estas la aplikaĵo, kiu veturas ene de la tunelo. Unue korektu la opon, legu la fazojn, kaj poste akiru realajn pruvojn por ĉio, kion la simulilo ne povas vidi.

La sekva trairado supozas, ke la ACL, la NAT-regulo kaj la tunnel-group-kunteksto estas antaŭ vi. Sen ili la eligo priskribas politikon, kiun vi ne povas kontroli.

Paŝo 1: skribu la internan fluon per simplaj vortoj

Priskribu la aplikaĵon antaŭ ol tajpi ion ajn. Gastiganto interne, kiu malfermas SSH al servilo malantaŭ la fora pordego, estas unu interna TCP-fluo kun specifa fonta pordo. Tio estas la fluo, kiun la ACL kaj la VPN-filtrilo taksas, do tio estas la fluo, kiun vi tajpas.

Skribu ĝin kiel frazon, poste traduku ĝin kampo post kampo:

packet-tracer input inside tcp 10.30.0.25 53000 10.40.0.50 22 detailed

Paŝo 2: elektu la enigan interfacon kaj la direkton

Enigo estas la interfaco, sur kiun la paketo alvenas, ne tiu, tra kiu ĝi foriras. Por LAN-gastiganto, kiu iniciatas, ĝi estas la interfaco inside. Por la revena paketo de la sama sesio, ĝi estas la interfaco outside, kaj la opo inversiĝas. Tajpi la celon kiel la fonton estas la dua plej kutima maniero akiri konvinkan sed ne gravan ALLOW.

Ankaŭ pordoj estas direktaj. La serva pordo apartenas al la celfako por iniciatita peto, kaj la efemera pordo de la kliento apartenas al la fontfako. Modelo kun TCP-celo 500 priskribas TCP-aplikaĵon aŭskultantan sur 500; ĝi ne fariĝas IKE-testo nur ĉar la nombro aperas en la komando.

Paŝo 3: legu la fazojn laŭ ordo

Ĉiu fazo en la eligo estas decido kun posedanto: itineta serĉo, ACL, NAT, poste VPN aŭ tunela elekto. Legu ilin laŭ la presita ordo kaj haltu ĉe la unua fazo, kiu malkongruas kun la dezajno.

NAT ofte trompas homojn. Se la tradukita fonto falas ekster la crypto ACL, kiu elektas trafikon por la tunelo, la fluo povas esti permesita kaj neniam enkapsuligita. La spuro presas la tradukitan adreson, do komparu ĝin kun la interesa trafiko de la tunelo, ne kun la origina adreso.

Paŝo 4: kontrolu, kiujn preterpasojn vi elektis

La formo detailed akceptas opciojn, kiuj saltas kontrolojn, kaj Cisco dokumentas opcion bypass-checks, kiu kovras ACL, VPN-filtrilon, uRPF kaj IPsec-falsigajn kontrolojn. ALLOW akirita kun ili preterpasitaj diras, ke la itinero kaj NAT funkcius, ne ke la politiko akceptus realan paketon. Notu la opciojn apud la rezulto.

Se vi bezonas la politikan respondon, rulu ĝin sen la preterpasoj. Se vi izolas itinetan demandon, rulu ĝin kun ili kaj marku la rezulton kiel itinetan respondon.

Paŝo 5: fermu la breĉon per la reala interŝanĝo

Simulita permeso haltas ĉe la ASA. Ĉu la fora pordego malĉifris la paketon, ĉu la servilo akceptis la konekton kaj ĉu revenis respondo, estas apartaj observoj. Uzu finpunktspektantojn aŭ mallarĝan kapton sur aprobita vojo.

Iuj spuraj kaj ripetaj opcioj sendas paketojn aŭ konservas staton. Sekvu la dokumentitan konduton por via eldono kaj via aprobita diagnoza proceduro anstataŭ trakti ĉiun varianton kiel nur-legan serĉon.

Kion la spuro ankoraŭ ne povas diri al vi

Tenu kvar aferojn en unu noto: la opo, la kongrua NAT-regulo, la tunelo aŭ politiko, kiu devus porti la fluon, kaj la direktspecifa observo. Sen ili posta inĝeniero ne povas apartigi lokan politikan decidon de establita kontrola ebeno kaj de funkcianta servo. Unua malsukceso sekvita de sukceso ankaŭ ne estas pruvo, ke la tunelo devis ekleviĝi intere; notu la fazon kaj la statoŝanĝon.

Komencu per la interna opo, haltu ĉe la unua fazo, kiu kontraŭdiras la dezajnon, kaj nur tiam ating la finpunktajn pruvojn. La spuro estas politika orakolo, ne livera kvitanco.