Kako modelirati tok VPN z ASA packet-tracer

Packet-tracer na ASA odgovori na ozko vprašanje: ali bi bil ta paket, ki tu vstopa s tem tuple, dovoljen in kam bi šel. Ne odgovori, ali oddaljeni konec kaj prejme. Običajna napaka je vnašanje zunanjega IKE tuple, ko je tisto, kar želite preizkusiti, aplikacija, ki vozi znotraj tunela. Najprej popravite tuple, preberite faze in nato pridobite resnične dokaze za vse, česar simulator ne vidi.

Spodnji sprehod predpostavlja, da so ACL, pravilo NAT in kontekst tunnel-group pred vami. Brez njih izhod opisuje politiko, ki je ne morete preveriti.

Korak 1: zapišite notranji tok s preprostimi besedami

Opišite aplikacijo, preden karkoli vtipkate. Gostitelj znotraj, ki odpre SSH do strežnika za oddaljenim prehodom, je en notranji tok TCP s posebnim izvornim vratom. To je tok, ki ga ocenjujeta ACL in filter VPN, zato je to tok, ki ga vnesete.

Zapišite ga kot stavek in ga nato prevedite polje za poljem:

packet-tracer input inside tcp 10.30.0.25 53000 10.40.0.50 22 detailed

Korak 2: izberite vhodni vmesnik in smer

Vhod je vmesnik, na katerem paket prispe, ne tisti, skozi katerega odide. Za gostitelja v LAN, ki začne, je to vmesnik inside. Za povratni paket iste seje je to vmesnik outside in tuple se obrne. Zapisati cilj kot vir je drugi najpogostejši način, da dobite prepričljiv, a nepomemben ALLOW.

Tudi vrata imajo smer. Vrata storitve spadajo v polje cilja pri sproženem zahtevku, začasna vrata odjemalca pa v polje vira. Model s ciljem TCP 500 opisuje aplikacijo TCP, ki posluša na 500; ne postane preskus IKE samo zato, ker se številka pojavi v ukazu.

Korak 3: berite faze po vrsti

Vsaka faza v izhodu je odločitev z lastnikom: iskanje poti, ACL, NAT, nato izbira VPN ali tunela. Berite jih v natisnjenem vrstnem redu in se ustavite pri prvi fazi, ki se ne ujema z zasnovo.

NAT pogosto preseneti. Če prevedeni vir pade izven crypto ACL, ki izbira promet za tunel, je tok lahko dovoljen in nikoli zapakiran. Sled tiska prevedeni naslov, zato ga primerjajte z zanimivim prometom tunela in ne z izvirnim naslovom.

Korak 4: preverite, katere obhode ste izbrali

Oblika detailed sprejema možnosti, ki preskočijo preverjanja, in Cisco dokumentira možnost bypass-checks, ki pokriva ACL, filter VPN, uRPF in preverjanja ponarejanja IPsec. ALLOW, pridobljen s temi preskočenimi, pove, da bi pot in NAT delovali, ne da bi politika sprejela resničen paket. Zapišite možnosti ob rezultatu.

Če potrebujete odgovor politike, zaženite brez obhodov. Če izolirate vprašanje usmerjanja, zaženite z njimi in rezultat označite kot odgovor o usmerjanju.

Korak 5: zaprite vrzel z resnično izmenjavo

Simulirano dovoljenje se ustavi na ASA. Ali je oddaljeni prehod dešifriral paket, ali je strežnik sprejel povezavo in ali se je vrnil odgovor, so ločena opažanja. Uporabite števce končnih točk ali ozek zajem na odobreni poti.

Nekatere možnosti trace in replay prenašajo pakete ali ohranjajo stanje. Sledite dokumentiranemu vedenju za svojo izdajo in odobreni diagnostični postopek, namesto da bi vsako različico obravnavali kot iskanje samo za branje.

Česa sled še vedno ne more povedati

Hranite štiri stvari v eni opombi: tuple, ustrezno pravilo NAT, tunel ali politiko, ki bi morala nositi tok, in opažanje, značilno za smer. Brez njih poznejši inženir ne more ločiti lokalne odločitve politike od vzpostavljene krmilne ravnine in od delujoče storitve. Prva neuspeh, ki mu sledi uspeh, tudi ni dokaz, da je moral tunel vmes vstati; zapišite fazo in spremembo stanja.

Začnite z notranjim tuplom, ustavite se pri prvi fazi, ki nasprotuje zasnovi, in šele nato segajte po dokazih s končnih točk. Sled je orakelj politike, ne potrdilo o dostavi.