Bakit nagbabago ang resulta ng port scan sa likod ng VPN exit?
Palitan ang exit at maaaring iba ang sagot ng port nang hindi gumagalaw ang serbisyo. Ihiwalay ang obserbasyon ng landas sa imbentaryo na talagang kailangan mo.
Patakbuhin ang parehong pagsusuri ng port mula sa linya ng opisina at mula sa VPN exit, at maaaring magkaiba ang dalawang sagot tungkol sa address na walang binago. Nagmumula ang agwat na iyon sa ruta at sa kung aling host ang sumagot, hindi sa kung buhay o patay ang serbisyo. Tatlong tanong ang naghihiwalay sa mga paliwanag na iyon: ano talaga ang itinanong ng probe, aling host ang sumagot, at ano ang naitala ng sarili mong server. Dumaan sa mga ito sa ganoong pagkakasunod-sunod at isulat ang bawat sagot bago lumipat sa susunod.
Ayusin ang probe bago ihambing ang dalawang pagtakbo
Ang isang salita ng estado ay maihahambing lamang sa ibang salita ng estado kapag pareho silang nagmula sa isang eksperimento. Limang field ang nagpapako nito: ang source address na nakita ng malayong panig, ang naresolba na destinasyon, ang port, ang uri ng scan at ang oras. Palitan ang alinman sa mga ito at nakagawa ka ng pangalawang eksperimento sa halip na sukatin ang una nang dalawang beses.
Suriin ang pinagmulan bago ang lahat, dahil maaaring buhay ang VPN client habang lumalabas pa rin ang trapiko sa pisikal na interface. Itanong sa malayong panig kung ano ang nakikita nito, pagkatapos itanong sa kernel kung aling interface ang pinili nito:
curl -s https://ifconfig.me
ip route get 203.0.113.20Dalawang address sa magkaibang network ang ibig sabihin ay nasa kamay na ang paliwanag, at ang natitirang mga pagsusuri ay magpapatunay lang nito. Kapag nagtugma sila, i-capture ang probe na bukas ang flag ng dahilan, upang bumalik ang estado na nakakabit sa isang paliwanag sa halip na tumayo nang mag-isa bilang hubad na salita. Ang uri ng scan ay kabilang din sa rekord na iyon, dahil inilalarawan nito kung ano ang itinanong, hindi kung ano ang bumalik. Ang estadong walang pinagmulan, walang pamamaraan at walang timestamp ay hindi maihahambing sa anuman:
nmap -sT -p 443,8443 --reason 203.0.113.20Itago ang output na iyon sa tabi ng rekord at hindi sa buffer ng pag-scroll na hindi makikita ng susunod na tao. Ang dalawang tapat na scan na hindi nagtutugma ay pagtatalo lamang kapag walang nagsulat ng mga kondisyon. Kapag nakapako ang mga kondisyon, maaaring magtugma ang mga resulta at sarado na ang tanong, o magkaiba sila at ang pagkakaiba ay katotohanan tungkol sa landas.
Alamin kung aling host ang tumapos ng pakikipagkamay
Ang natapos na pakikipagkamay ay nagpapatunay na may host na tumapos nito, at ang host na iyon ay hindi kailangang maging prosesong nasa isip mo. Ang load balancer, reverse proxy o SYN proxy ay maaaring sumagot bago pa makisali ang tunay na server, na karaniwang disenyo at hindi sintomas. Ang valid na sertipiko para sa inaasahang pangalan ay hindi rin nagpapaliit nito, dahil inilalarawan ng sertipiko ang ugnayan ng serbisyo at walang sinasabi tungkol sa kung aling makina ang tumapos ng koneksyon.
Ang sanggunian ng estado ng port ng Nmap ay itinuturing itong batayan: itinatala ng estado kung ano ang naobserbahan ng probe mula sa pinagpadalhan, hindi katangian ng port. Basahin ang salita ng estado nang ganoon at ang dalawang pagtakbo na hindi nagtugma ay magsisimulang magmukhang magkakatugma sa halip na magkasalungat, habang lumilipat ang tanong mula sa kung bukas ang port patungo sa kung sino ang nakatayo sa harap nito.
Sagutin ang ikalawang tanong sa backend at hindi mula sa labas. Ang frontend na tumatanggap ng koneksyon at pagkatapos ay hindi umabot sa upstream nito ay gumagawa ng eksaktong panlabas na larawan ng malusog na serbisyo na may mabagal na aplikasyon. Tanging ang sariling rekord ng upstream ang naghihiwalay sa dalawang kaso:
tail -n 5 /var/log/nginx/access.log
ss -ltnp 'sport = :443'Ipinapakita ng log line ang client address na talagang nakita ng aplikasyon, at ipinapakita ng ikalawang command kung ang prosesong humahawak ng port 443 ay ang aplikasyon mo o isang bagay sa harap nito. Kung hindi nagtutugma ang dalawa tungkol sa kung aling address ang kumonekta, tinitingnan mo ang dalawang binti ng isang kahilingan at dapat sabihin iyon ng ticket.
Suriin ang sarili mong mga patakaran bago sisihin ang tunnel
Ang sadyang patakaran ang pinakakaraniwang dahilan kung bakit sumasagot ang isang port sa isang network at hindi sa iba, at ito ang pinakamababang kawili-wiling paliwanag na makukuha. Umiiral ang mga patakaran sa pag-access upang payagan ang isang pinagmulan at itapon ang iba, kaya ang pagbabago ng exit ay eksaktong kaganapang isinulat para sa kanila. Kaya ang ibang estado sa pamamagitan ng VPN ay hindi nagpapakita na iniinspeksyon ng provider ang trapiko. Ipinapakita nito na iba na ang source address mo ngayon, na isang mas maliit na pahayag.
Ang mga patakarang iyon ay mababasa sa server, kaya basahin ang mga ito sa halip na manghula tungkol sa gitna ng network. Ilista ang mga patakaran ng filter na nagbabanggit ng alinman sa dalawang saklaw ng address, pagkatapos suriin kung umabot man ang koneksyon sa daemon:
nft list ruleset | grep -n -e 203.0.113 -e 198.51.100
journalctl -u sshd -n 50 | grep 203.0.113Ang walang laman na ikalawang resulta ay nagbibigay-kaalaman, dahil walang umabot sa daemon at ang tanong ay pag-aari ng isang filter, isang security group o ng landas mismo. Ang isang hit ay nangangahulugang nakita ng serbisyo ang pinagmulan mo at pinili ang sagot nito, at ang desisyong iyon ay karaniwang nakasulat sa patakarang mababasa mo. Wala sa dalawang resulta ang sumusuporta sa kuwento tungkol sa provider, at pareho silang mas mura suriin kaysa sa paghuli ng packet.
Basahin ang transport, sertipiko at tugon nang hiwalay
Tatlong layer ang gumagawa ng tatlong obserbasyon, at ang probe na sumusubok sa isa sa mga ito ay hindi makapag-uulat tungkol sa dalawa pa. Itago ang mga ito bilang hiwalay na linya sa rekord sa halip na tiklupin sa isang hatol, dahil bawat linya ay nabigo sa sarili nitong paraan at ang paraan ng pagkabigo ay nagsasabi kung saan titingin sa susunod.
| Observation | What it settles | What it leaves open |
|---|---|---|
| Connection completed | A host on the path accepted the handshake | Which host, and whether its upstream is reachable |
| Certificate valid for the name | The endpoint holds a credential for that name | Whether the process behind it is the one you meant |
| Expected response body | The application handled the request | Anything about other ports or other paths |
| Connection refused | A host replied and nothing was listening | Whether a filter sits ahead of the refused port |
| Timeout | No reply arrived before the deadline | Drop, blackhole route or an overloaded host |
Isang command ang gumagawa ng unang tatlong linya laban sa serbisyong kontrolado mo. Ilagay ang output nito sa rekord sa tabi ng scan at hindi sa chat message:
curl -v --resolve office.example:443:203.0.113.20 https://office.example/Basahin ang output sa pagkakasunod-sunod: sinasagot ng pakikipagkamay ang tanong ng transport, sinasagot ng paksa ng sertipiko ang tanong ng pangalan, at sinasagot ng katawan ng tugon ang tanong ng aplikasyon. Kapag nagtagumpay ang linya ng pakikipagkamay at hindi ang linya ng tugon, mayroon kang frontend na sira ang upstream at hindi port na naka-block. Iyon ay ibang ticket sa binuksan mo, at sulit sabihin nang malinaw.
Tapusin sa pamamagitan ng pagsulat ng apat na katotohanan sa ticket: source address, uri ng scan, host na sumagot at oras. Lahat ng kailangan ng susunod na paghahambing ay nabubuhay sa apat na iyon, at ang kukuha ng kaso sa susunod ay walang terminal history mo. Kung hindi mo mapupunan ang lahat ng apat, hindi pa tapos ang pagtakbo.