VPN-virran mallintaminen ASA packet-tracerilla

ASA:n packet-tracer vastaa kapeaan kysymykseen: sallittaisiinko tämä paketti, joka saapuu tänne tällä monikolla, ja minne se menisi. Se ei vastaa siihen, saako kaukopää mitään. Tavallinen virhe on syöttää ulompi IKE-monikko, kun testattava asia on sovellus, joka kulkee tunnelin sisällä. Korjaa ensin monikko, lue vaiheet ja hanki sitten todelliset todisteet kaikesta, mitä simulaattori ei näe.

Alla oleva läpikäynti olettaa, että ACL, NAT-sääntö ja tunnel-group-konteksti ovat edessäsi. Ilman niitä tuloste kuvaa käytäntöä, jota et voi tarkistaa.

Vaihe 1: kirjoita sisempi virta selkein sanoin

Kuvaile sovellus ennen kuin kirjoitat mitään. Sisäpuolen isäntä, joka avaa SSH:n kaukokäytävän takana olevaan palvelimeen, on yksi sisempi TCP-virta, jolla on tietty lähdeportti. Se on virta, jota ACL ja VPN-suodatin arvioivat, joten se on virta, jonka kirjoitat.

Kirjoita se lauseena ja käännä se sitten kenttä kentältä:

packet-tracer input inside tcp 10.30.0.25 53000 10.40.0.50 22 detailed

Vaihe 2: valitse saapumisliitäntä ja suunta

Saapuminen on liitäntä, jolle paketti saapuu, ei se, jota pitkin se lähtee. Aloittavalle LAN-isännälle se on inside-liitäntä. Saman istunnon paluupaketille se on outside-liitäntä, ja monikko kääntyy. Kohde lähteenä kirjoittaminen on toiseksi yleisin tapa ansaita vakuuttava mutta merkityksetön ALLOW.

Portit ovat myös suunnattuja. Palvelun portti kuuluu kohdekenttään aloitetussa pyynnössä, ja asiakkaan efemeerinen portti kuuluu lähdekenttään. Malli, jonka TCP-kohde on 500, kuvaa TCP-sovellusta, joka kuuntelee porttia 500; siitä ei tule IKE-testiä vain siksi, että luku esiintyy komennossa.

Vaihe 3: lue vaiheet järjestyksessä

Jokainen tulosteen vaihe on päätös, jolla on omistaja: reittihaku, ACL, NAT ja sitten VPN- tai tunnelivalinta. Lue ne tulostetussa järjestyksessä ja pysähdy ensimmäiseen vaiheeseen, joka on ristiriidassa suunnitelman kanssa.

NAT yllättää monia. Jos käännetty lähde jää tunnelin liikennettä valitsevan crypto ACL:n ulkopuolelle, virta voidaan sallia eikä sitä koskaan kapseloida. Jäljitys tulostaa käännetyt osoitteen, joten vertaa sitä tunnelin kiinnostavaan liikenteeseen äläkä alkuperäiseen osoitteeseen.

Vaihe 4: tarkista, mitkä ohitukset valitsit

detailed-muoto ottaa vaihtoehtoja, jotka ohittavat tarkistuksia, ja Cisco dokumentoi bypass-checks-vaihtoehdon, joka kattaa ACL:n, VPN-suodattimen, uRPF:n ja IPsec-huijausyritysten tarkistukset. Näiden ohittaessa saatu ALLOW sanoo, että reitti ja NAT toimisivat, ei sitä että käytäntö hyväksyisi oikean paketin. Kirjaa vaihtoehdot tuloksen viereen.

Jos tarvitset käytännön vastauksen, aja se ilman ohituksia. Jos eristät reitityskysymystä, aja se niiden kanssa ja merkitse tulos reititysvastaukseksi.

Vaihe 5: sulje aukko todellisella vaihdolla

Simuloitu lupa pysähtyy ASA:han. Se, purkiko kaukokäytävä paketin salauksen, hyväksyikö palvelin yhteyden ja tuliko vastaus takaisin, ovat erillisiä havaintoja. Käytä päätepistelaskureita tai kapeaa kaappausta hyväksytyllä polulla.

Jotkin trace- ja replay-vaihtoehdot lähettävät paketteja tai säilyttävät tilan. Noudata julkaisusi ja hyväksytyn diagnostiikkamenettelysi dokumentoitua toimintaa sen sijaan, että kohtelisit jokaista muunnelmaa vain lukemisena.

Mitä jäljitys ei vieläkään voi kertoa sinulle

Pidä neljä asiaa yhdessä muistiinpanossa: monikko, vastaava NAT-sääntö, tunneli tai käytäntö, jonka pitäisi kuljettaa virta, ja suuntakohtainen havainto. Ilman niitä myöhempi insinööri ei voi erottaa paikallista käytäntöpäätöstä vakiintuneesta ohjaustasosta ja toimivasta palvelusta. Ensimmäinen epäonnistuminen, jota seuraa onnistuminen, ei sekään todista, että tunneli oli pakko nousta välissä; kirjaa vaihe ja tilan muutos.

Aloita sisemmästä monikosta, pysähdy ensimmäiseen vaiheeseen, joka on ristiriidassa suunnitelman kanssa, ja vasta sitten hae päätepistetodisteita. Jäljitys on käytännön oraakkeli, ei toimituskuitti.