Kā modelēt VPN plūsmu ar ASA packet-tracer

Packet-tracer ASA atbild uz šauru jautājumu: vai šis pakets, kas šeit ienāk ar šo tuple, tiktu atļauts, un kur tas dotos. Tas neatbild, vai tālais gals kaut ko saņem. Ierastā kļūda ir padot ārēju IKE tuple, kad tas, ko vēlaties pārbaudīt, ir lietojumprogramma, kas brauc tunelī. Vispirms izlabojiet tuple, izlasiet fāzes un pēc tam iegūstiet reālus pierādījumus visam, ko simulators neredz.

Tālāk aprakstītā gaita pieņem, ka ACL, NAT noteikums un tunnel-group konteksts ir jums priekšā. Bez tiem izvade apraksta politiku, ko nevarat pārbaudīt.

1. solis: ierakstiet iekšējo plūsmu vienkāršiem vārdiem

Aprakstiet lietojumprogrammu pirms kaut ko ierakstāt. Iekšējais resursdators, kas atver SSH uz serveri aiz tālās vārtejas, ir viena iekšēja TCP plūsma ar konkrētu avota portu. Tā ir plūsma, ko vērtē ACL un VPN filtrs, tāpēc tā ir plūsma, ko ievadāt.

Ierakstiet to kā teikumu un pēc tam iztulkojiet lauku pa laukam:

packet-tracer input inside tcp 10.30.0.25 53000 10.40.0.50 22 detailed

2. solis: izvēlieties ieejas saskarni un virzienu

Ieeja ir saskarne, kurā pakets ierodas, nevis tā, pa kuru tas aiziet. LAN resursdatoram, kas uzsāk, tā ir inside saskarne. Tās pašas sesijas atgaitas paketam tā ir outside saskarne, un tuple apgriežas. Rakstīt galamērķi kā avotu ir otrs visizplatītākais veids, kā iegūt pārliecinošu, bet nebūtisku ALLOW.

Arī portiem ir virziens. Pakalpojuma ports pieder galamērķa laukam uzsāktam pieprasījumam, un klienta īslaicīgais ports pieder avota laukam. Modelis ar TCP galamērķi 500 apraksta TCP lietojumprogrammu, kas klausās uz 500; tā nekļūst par IKE testu tikai tāpēc, ka skaitlis parādās komandā.

3. solis: lasiet fāzes secībā

Katra izvades fāze ir lēmums ar īpašnieku: maršruta meklēšana, ACL, NAT, pēc tam VPN vai tuneļa izvēle. Lasiet tās drukātajā secībā un apstājieties pirmajā fāzē, kas neatbilst projektam.

NAT bieži pieviļ cilvēkus. Ja tulkotais avots nonāk ārpus crypto ACL, kas atlasa satiksmi tunelim, plūsma var tikt atļauta un nekad netikt iekapsulēta. Izsekošana izdrukā tulkoto adresi, tāpēc salīdziniet to ar tuneļa interesanto satiksmi, nevis ar sākotnējo adresi.

4. solis: pārbaudiet, kuras apiešanas izvēlējāties

Forma detailed pieņem opcijas, kas izlaiž pārbaudes, un Cisco dokumentē bypass-checks opciju, kas aptver ACL, VPN filtru, uRPF un IPsec viltošanas pārbaudes. ALLOW, kas iegūts ar tām izlaistām, saka, ka maršruts un NAT darbotos, nevis ka politika pieņemtu reālu paketu. Ierakstiet opcijas blakus rezultātam.

Ja jums vajag politikas atbildi, palaidiet to bez apiešanām. Ja izolējat maršrutēšanas jautājumu, palaidiet to ar tām un atzīmējiet rezultātu kā maršrutēšanas atbildi.

5. solis: aizveriet starpību ar īstu apmaiņu

Simulēta atļauja apstājas pie ASA. Vai tālā vārteja atšifrēja paketu, vai serveris pieņēma savienojumu un vai atbilde atgriezās, ir atsevišķi novērojumi. Izmantojiet galapunktu skaitītājus vai šauru uztveri apstiprinātā ceļā.

Dažas trace un replay opcijas pārraida paketus vai saglabā stāvokli. Ievērojiet dokumentēto uzvedību savai versijai un apstiprinātajai diagnostikas procedūrai, nevis uzskatiet katru variantu par tikai lasāmu meklēšanu.

Ko izsekošana joprojām nevar pateikt

Glabājiet četras lietas vienā piezīmē: tuple, atbilstošo NAT noteikumu, tuneli vai politiku, kam jānes plūsma, un virzienam raksturīgo novērojumu. Bez tiem vēlāks inženieris nevar atdalīt vietēju politikas lēmumu no izveidotas vadības plaknes un no strādājoša pakalpojuma. Pirmā neveiksme, kam seko panākums, arī nav pierādījums, ka tunelim bija jāceļas pa vidu; ierakstiet fāzi un stāvokļa izmaiņas.

Sāciet ar iekšējo tuple, apstājieties pirmajā fāzē, kas ir pretrunā ar projektu, un tikai tad sniedzieties pēc galapunktu pierādījumiem. Izsekošana ir politikas orākuls, nevis piegādes kvīts.