Wireshark käitub Etherneti liidesel laitmatult ja siis, VPN-adapteril, lakkab tunnel liiklust läbi laskmast hetkel, mil püüdmine algab. Püüdmise aken täitub edasi, nii et tööriist näeb terve välja, samal ajal kui selle all olev ühendus sureb. Valimatu režiim on tavaline põhjus, sest tunneldraiverit, millelt küsitakse iga kaadrit segmendil, mida tal ei ole, võib sattuda olekusse, kus midagi välja ei lähe.

Lülitage see valik kõigepealt välja ja otsustage seejärel, millist kihti te tegelikult näha tahate.

Kaks adapterit, kaks erinevat vaadet

VPN-klient esitab tavaliselt kaks liidest: füüsilise, mis kannab krüpteeritud transporti, ja virtuaalse, mis kannab dekrüpteeritud sisemist liiklust. Need vastavad erinevatele küsimustele. Füüsiline püüdmine näitab lõpp-punkte, porte ja paketi suurusi, virtuaalne aga rakendusprotokolle nii, nagu tunnel need kohale toimetab. Ühe valimine ilma teadmata, millist küsimust te esitate, raiskab püüdmise.

Kumbki vaade ei ole teise ülemhulk ja üks püüdmine vastab harva mõlemale küsimusele korraga.

Valige liides küsimuse, mitte loendi järjekorra järgi, sest PPP-stiilis klient võib esitada oma adapteri Etherneti seadmena ja kuvatav nimi ei ütle teile, millise kihi valisite. Püüdmine lüüsil või peegelportil lisab kolmanda vaate, mis näitab teed pärast edasisaatmist, ja just seal muutuvad asümmeetriline marsruutimine ja filtreerimine nähtavaks.

Capture pointWhat it showsWhat it cannot show
Physical interfaceOuter endpoints, ports, packet sizesAny inner payload
Tunnel interfaceDecrypted inner trafficWhat the VPN added around it
Gateway or mirrorForwarded path after the tunnelThe client's own decision process

Miks valimatu režiim tunnel-adapteri rikub

Valimatu režiim palub draiveril edastada kaadreid, mis ei ole hostile adresseeritud, mis on mõistlik jagatud Etherneti segmendil ja väga vähe mõistlik punkt-punkt-tunnelis. Mõned draiverid käsitlevad taotlust rahulikult; teised lakkavad saatmisliiklust järjekorrast välja võtmast ja liides muutub vaikselt mustaks auguks. Püüdmine registreerib endiselt seda, mis saabub, nii et fail näeb välja nagu tõestus töötavast ühendusest. Just see lünk faili näitatu ja liidese tehtu vahel on kogu lõks.

Lülitage valik välja enne esimest paketti, hoidke püüdmisfilter kitsas ja kasutage väikest puhvrit. Suur ringpuhver hõivatud liidesel kaotab täpselt need kaadrid, millel oli tähtsust, andes püüdmise, mis on terviklik kõikjal peale koha, kus rike oli.

Kui ühendus keset püüdmist takerdub, peatage see ja jälgige taastumist. See üks tähelepanek eristab püüdmise kõrvalmõju tunnelis olevast tõelisest rikkest ja võtab vähem aega kui mis tahes filtrite häälestamine.

IPsec-püüdmise loetavaks muutmine

IPsec-püüdmine iseenesest ei ole loetav, sest ESP krüpteerib kandevõime. Wireshark saab selle dekodeerida, kui annate seansi võtmed, või kui ta suudab jälgida IKE läbirääkimist, mis need lõi, mis tähendab, et käepigistus peab olema samas failis.

Võtmed aeguvad. Pärast seda, kui pooled on võtmeid uuendanud, lakkab vanade võtmete komplekt püüdmise keskel töötamast ja tulemus näeb välja nagu dekoodri viga, mitte ajapiir.

Järgige tarnija dokumenteeritud võtmevormingut, selle asemel et importida materjali seostamatust allikast, ja oodake, et mõned platvormid keelduvad kogu töövoost. Kui lüüs ei anna võtmeid ega luba püüdmist, leppige sellega, et kandevõime ei ole teie asukohast uuritav. Lõpp-punktide logid ja liidese loendurid on ülejäänud tõendid ja tavaliselt piisavad marsruutimise küsimuse jaoks.

Püüdmine, mida saate turvaliselt jagada

Sisemine püüdmine on lähemal volituste väljavõttele kui logile. See võib sisaldada nimesid, aadresse ja avateksti protokollidest, mis kirjutati eeldusel, et keegi ei loe neid kunagi, mistõttu just fail ise on tundlik artefakt, mitte analüüs.

Veenduge, et host ja võrk on sellised, kus teil on lubatud püüda, märkige tulemuse juurde nii liides kui filter, piirake seanss mõne minutiga, mis küsimusele vastavad, ja eemaldage fail, kui olete lõpetanud. Kui seda tuleb jagada, kirjeldage esmalt voogu või eemaldage kandevõime.

Seejärel korrake algset kasutaja ülesannet. Püüdmine, mis tõestab, et pakett saabus, ei ole tõestus, et rakendus vastuse vastu võttis, ja nende kahe erinevus on tavaliselt kohas, kus asub tegelik rike.

Seotud artiklid