Nmap nagpapakita ng ibang resulta sa VPN? Ipin ang target
Maaaring maresolba ang pangalan ng host sa ibang address kapag nakataas ang tunnel. Panatilihing naka-pin ang numeric na target bago bigyang kahulugan ang mga pagbabago sa estado ng port.
Dalawang port scan ng parehong website ay maaaring hindi magkasundo dahil naresolba ang pangalan sa ibang address sa pagitan ng mga run, hindi dahil binago ng tunnel ang ipinapakita ng target. Ang pangalan ng host ay isang utos sa paghahanap, at sinusunod ito ng Nmap sa oras ng scan. Kapag sumagot ang resolver ng ibang record, ibang makina ang sinukat ng ikalawang scan.
I-pin ang numeric na address at magiging makabuluhan muli ang paghahambing. Ang lahat ng iba pa sa ulat, mula sa timing hanggang sa mga intermediary na device, ay nananatiling hiwalay na variable na nangangailangan ng sariling kontrol.
Dalawang eksperimento na magkapareho sa ulat
Ihambing ang isang pangalan sa sarili nito at binago mo ang hindi bababa sa dalawang bagay nang sabay: ang landas na tinatahak ng iyong mga packet at ang destinasyong ibinalik ng resolver. Ang pagkakaiba sa output ay hindi maaaring iugnay sa alinman sa dalawa. Ang kalabuan na iyon ang karaniwang dahilan kung bakit ang scan bago-at-pagkatapos ay nagiging debate na walang makaresolba.
Ihambing ang isang address sa sarili nito at ang destinasyon ay nakaayos ayon sa konstruksiyon. Ang lahat ng iba pa ay kabilang sa landas, sa source address, sa filtering sa pagitan, o sa sariling estado ng makina. Nag-alis ka ng isang variable, na hindi katulad ng pag-alis sa lahat.
Isulat kung alin sa dalawang eksperimentong iyon ang aktwal mong ginawa bago kumuha ng anumang konklusyon mula sa talahanayan ng port. Ang pagkakaiba ay parang akademiko hanggang may ulat na magsabi na hinarang ng VPN ang isang port na hindi kailanman nakabukas sa address na naabot mo sa ikalawang pagkakataon.
| Comparison | What stays fixed | What a difference can mean |
|---|---|---|
| Name against name | The string you typed | Resolver answer, answer order or split-horizon policy changed |
| Address against address | The numeric destination | Source path, filtering or service placement changed |
Iresolba muna, pagkatapos i-scan ang naitalang address
Ihiwalay ang pagresolba sa pagsusuri upang mapunta ang dalawang katotohanan sa magkaibang lugar. Tanungin ang system kung ano ang niresolba nito, itago ang sagot na iyon, pagkatapos ibigay sa Nmap ang literal na address. Ulitin ang parehong dalawang utos habang nakababa at nakataas ang tunnel.
getent hosts scan.example.net dig +short scan.example.net A nmap -Pn -sV -p 443,8443 192.0.2.40
Mahalaga ang flag na -Pn dito, dahil ang host na hindi pinapansin ang discovery probes ay maiuulat na down at ang walang laman na resulta ay mabibigyang-kahulugan nang mali bilang saradong port. Gamitin lamang ang -sV laban sa mga destinasyong inaprubahan ng operator; mas maingay ang version probing kaysa sa simpleng koneksiyon at kabilang ito sa nakasulat na saklaw.
Ang reference ng target specification ng Nmap ay malinaw na nagsasabi na ang pangalan ng host ay niresolba sa address bago ang scan at kapag maraming address ang bumalik ay ini-scan ng tool ang una maliban kung hilingin mo ang lahat. Walang anuman sa pag-uugaling iyon na espesipiko sa VPN. Ang split DNS, ibang resolver, o load balancer na sumasagot sa bagong pagkakasunod-sunod ay gumagawa ng parehong epekto nang walang anumang tunnel.
Panatilihin ang niresolbang halaga sa tabi ng output ng scan, kasama ang pamilya ng address, set ng flag, at timestamp. Ang reverse lookup na nagbabalik ng pangalan ng kumpanya ay isa pang obserbasyon, hindi patunay kung aling backend ang sumagot.
Ano ang maaari at hindi maaaring sabihin ng nabagong estado ng port
Kapag naka-pin ang destinasyon, ang port na lumilipat mula bukas patungong filtered ay karaniwang tumuturo sa landas. Isipin ang isang ACL sa itaas, isang stateful firewall, o isang provider na tinatrato ang tunnel egress nang iba kaysa sa residential egress. Paliliitin ito sa pamamagitan ng pagsubok ng pangalawang aprubadong address sa parehong subnet kapag pinapayagan ng saklaw, dahil ang pagpapalit ng pangalan ng host ay magbabalik ng tanong ng resolver. Isang variable bawat run ang buong pamamaraan.
Ang port na nananatiling bukas habang nagbabago ang banner ng serbisyo ay ibang kuwento. Ang pattern na iyon ay umaangkop sa isang front-end na naghahati ng mga koneksiyon sa mga backend, at walang dami ng pag-scan mula sa iyong panig ang makapangalan sa nangungupahan sa likod nito.
Ang hindi kailanman sinasabi ng scan ay intensiyon. Ang filtered na port ay resulta ng patakaran, hindi patunay na may pumili ng iyong tunnel, at ang bukas na port ay hindi patunay na ang aplikasyon sa likod nito ay maglilingkod sa iyo. Iugnay sa mga log ng component na pinapatakbo mo bago isulat ang alinman sa dalawang kuwento.
Itala ang mga resulta upang malampasan ng paghahambing ang pagsusuri
Ang kapaki-pakinabang na tala ay naglalaman ng hiniling na pangalan, niresolbang address at ang pamilya nito, eksaktong mga flag, ginagamit na source address, at awtorisasyong sumasaklaw sa destinasyon. Idagdag ang oras, dahil umiikot ang mga sagot ng DNS at ang ulat na walang timestamp ay nag-aanyaya ng parehong debate nang dalawang beses. Idagdag din ang bersiyon ng scanner, dahil nagbabago ang default na pag-uugali sa pagsusuri sa pagitan ng mga release. Kung gumamit ang dalawang run ng magkaibang pamamaraan, ituring silang magkaibang eksperimento at sabihin iyon sa pamagat, hindi sa footnote.
Lagyan ng label ang natuklasan ayon sa kung ano ito: magkaibang destinasyon, magkaibang source path, o pagkakaibang hindi pa maipaliwanag. Ang bokabularyo na iyon ay nagpapanatiling tapat ang ulat ng scan at pumipigil sa sagot ng resolver na muling mailathala bilang kaganapan ng interception ng VPN. Ang susunod na hakbang ay karaniwang isa pang run na naka-pin ang address, hindi isang mas malawak na scan.