Pinapatay ng promiscuous mode sa VPN adapter ang koneksyon
Ang paghuli sa isang tunnel adapter ay maaaring pahintuin ang pagpapasa nito. Patayin ang promiscuous mode, piliin ang layer na sumasagot sa tanong, at ituring ang file na lihim.
Perpektong gumagana ang Wireshark sa isang Ethernet interface at pagkatapos, sa isang VPN adapter, humihinto ang tunnel sa pagpapasa ng trapiko sa sandaling magsimula ang paghuli. Patuloy na napupuno ang window ng paghuli, kaya mukhang malusog ang tool habang namamatay ang koneksyon sa ilalim nito. Ang promiscuous mode ang karaniwang dahilan, dahil ang driver ng tunnel na hinihilingan ng bawat frame sa isang segment na wala nito ay maaaring mauwi sa isang estado kung saan walang lumalabas.
Patayin muna ang opsyong iyon, pagkatapos ay magpasya kung aling layer ang talagang kailangan mong makita.
Dalawang adapter, dalawang magkaibang pananaw
Karaniwang nagpapakita ang VPN client ng dalawang interface: ang pisikal na nagdadala ng naka-encrypt na transport, at isang virtual na nagdadala ng na-decrypt na panloob na trapiko. Sumasagot sila sa magkaibang tanong. Ipinapakita ng pisikal na paghuli ang mga endpoint, port at laki ng packet, habang ang virtual ay nagpapakita ng mga protocol ng application ayon sa paghahatid ng tunnel. Ang pagpili ng isa nang hindi alam kung anong tanong ang itinatanong ay nagsasayang ng paghuli.
Walang pananaw na superset ng isa pa, at ang isang paghuli ay bihirang sumagot sa dalawang tanong nang sabay.
Piliin ang interface batay sa tanong at hindi sa pagkakasunod-sunod sa listahan, dahil ang client na tulad ng PPP ay maaaring ipakita ang adapter nito bilang Ethernet device at hindi sasabihin ng ipinapakitang pangalan kung aling layer ang pinili mo. Ang paghuli sa isang gateway o mirror port ay nagdadagdag ng ikatlong pananaw, na nagpapakita ng landas pagkatapos ng pagpapasa, at doon nagiging nakikita ang asymmetric routing at filtering.
| Capture point | What it shows | What it cannot show |
|---|---|---|
| Physical interface | Outer endpoints, ports, packet sizes | Any inner payload |
| Tunnel interface | Decrypted inner traffic | What the VPN added around it |
| Gateway or mirror | Forwarded path after the tunnel | The client's own decision process |
Bakit sinisira ng promiscuous mode ang isang tunnel adapter
Hinihiling ng promiscuous mode sa driver na maghatid ng mga frame na hindi naka-address sa host, na may saysay sa isang pinagsasaluhang Ethernet segment at napakakaunting saysay sa isang point-to-point tunnel. Ang ilang driver ay mahinahong humahawak sa kahilingan; ang iba ay humihinto sa pag-alis ng transmit traffic mula sa queue, at tahimik na nagiging black hole ang interface. Nagtatala pa rin ang paghuli ng dumarating, kaya ang file ay parang ebidensya ng gumaganang link. Ang agwat na iyon sa pagitan ng ipinapakita ng file at ng ginawa ng interface ang buong bitag.
Patayin ang opsyon bago ang unang packet, panatilihing makitid ang filter ng paghuli at gumamit ng maliit na buffer. Ang malaking ring buffer sa abalang interface ay nagtatapon ng eksaktong mga frame na mahalaga, na nagbubunga ng paghuling kumpleto sa lahat ng lugar maliban sa kung saan naroon ang depekto.
Kung huminto ang link sa gitna ng paghuli, ihinto ito at panoorin ang pagbawi. Ang nag-iisang obserbasyong iyon ay naghihiwalay ng side effect ng paghuli mula sa tunay na depekto ng tunnel, at mas kaunti ang oras kaysa sa anumang pag-tune ng filter.
Gawing nababasa ang isang paghuli ng IPsec
Ang paghuli ng IPsec nang mag-isa ay hindi nababasa, dahil ini-encrypt ng ESP ang payload. Maaaring i-decode ito ng Wireshark kapag ibinigay mo ang mga susi ng session, o kapag masusubaybayan nito ang negosasyon ng IKE na lumikha sa mga ito, na nangangahulugang ang handshake ay dapat nasa parehong file.
Nag-expire ang mga susi. Matapos i-renew ng magkabilang panig ang mga susi, hihinto ang isang set ng lumang susi sa paggana sa gitna ng paghuli, at ang resulta ay parang bug ng decoder kaysa hangganan ng oras.
Sundin ang dokumentadong format ng susi ng vendor sa halip na mag-import ng materyal mula sa walang kaugnayang source, at asahan na ang ilang platform ay tuluyang tatanggi sa buong workflow. Kapag hindi ibinigay ng gateway ang mga susi o hindi pinapayagan ang paghuli, tanggapin na hindi masisiyasat ang payload mula sa kinaroroonan mo. Ang mga log ng endpoint at counter ng interface ang natitirang ebidensya, at kadalasan ay sapat na para sa isang tanong sa routing.
Isang paghuli na maaari mong ibahagi nang ligtas
Ang panloob na paghuli ay mas malapit sa pagtatapon ng mga kredensyal kaysa sa isang log. Maaaring maglaman ito ng mga pangalan, address at plaintext mula sa mga protocol na isinulat sa pag-aakalang walang sinuman ang babasa sa mga ito, na ginagawang sensitibong artifact ang file mismo at hindi ang pagsusuri.
Tiyakin na ang host at network ay yaong pinapayagan kang maghuli, itala ang interface at filter kasama ng resulta, limitahan ang session sa ilang minutong sumasagot sa tanong, at alisin ang file kapag tapos ka na. Kung kailangang ibahagi, ilarawan ang daloy o alisin muna ang payload.
Pagkatapos, ulitin ang orihinal na gawain ng gumagamit. Ang paghuling nagpapatunay na may dumating na packet ay hindi patunay na tinanggap ng application ang sagot, at ang pagkakaiba ng dalawa ay kadalasan ang lugar kung saan naroon ang tunay na depekto.