Miks muutuvad pordiskaneerimise tulemused VPN-i väljundpunkti taga?
Muutke väljundit ja port võib vastata teisiti, ilma et teenus liiguks. Eraldage tee vaatlus loendist, mida tegelikult vajate.
Käivitage sama pordikontroll kontoriliinilt ja VPN-i väljundpunktist ning kaks vastust võivad lahkneda aadressi osas, mida keegi ei muutnud. See vahe tuleb marsruudist ja sellest, milline host vastas, mitte sellest, kas teenus töötab. Kolm küsimust eristavad neid seletusi: mida sond tegelikult küsis, milline host vastas ja mida teie enda server salvestas. Käige need selles järjekorras läbi ja kirjutage iga vastus üles enne järgmise juurde liikumist.
Parandage sond enne kahe jooksu võrdlemist
Olekusõna saab võrrelda teise olekusõnaga ainult siis, kui mõlemad pärinevad samast katsest. Viis välja kinnistavad selle: allikaaadress, mida kaugpool nägi, lahendatud sihtkoht, port, skaneerimise tüüp ja aeg. Muutke ükskõik millist neist ja olete teinud teise katse, mitte mõõtnud esimest kaks korda.
Kontrollige allikat enne kõike muud, sest VPN-kliient võib töötada, samal ajal kui liiklus väljub endiselt füüsilise liidese kaudu. Küsige kaugpoolelt, mida see näeb, ja seejärel küsige tuumalt, millise liidese see valis:
curl -s https://ifconfig.me
ip route get 203.0.113.20Kaks aadressi erinevates võrkudes tähendavad, et seletus on juba käes, ja ülejäänud kontrollid ainult kinnitavad seda. Kui need ühtivad, salvestage sond põhjuse lipuga sees, et olek tuleks tagasi seletusega seotult, mitte ei seisaks üksi palja sõnana. Skaneerimise tüüp kuulub samuti sellesse kirjesse, sest see kirjeldab, mida küsiti, mitte mida tagasi tuli. Olekut ilma allika, meetodi ja ajatemplita ei saa millegagi võrrelda:
nmap -sT -p 443,8443 --reason 203.0.113.20Hoidke see väljund kirje kõrval, mitte kerimispuhvris, mida järgmine inimene ei näe. Kaks ausat skaneerimist, mis lahknevad, on vaidlus ainult siis, kui keegi ei kirjutanud tingimusi üles. Kui tingimused on fikseeritud, kas tulemused ühtivad ja küsimus on suletud, või need erinevad ja erinevus on fakt tee kohta.
Tehke kindlaks, milline host lõpetas kätluse
Lõpetatud kätlus tõestab, et mõni host lõpetas selle, ja see host ei pea olema protsess, mis teil silme ees on. Koormusjaotur, pöördproksi või SYN-proksi võivad vastata enne, kui tegelik server osaleb, mis on tavaline disain, mitte sümptom. Oodatava nime jaoks kehtiv sertifikaat ei kitsenda seda samuti, sest sertifikaat kirjeldab teenusesuhet ega ütle midagi selle kohta, milline masin ühenduse lõpetas.
Nmap’i porduseisundite viide peab seda elementaarseks: olek registreerib, mida sond sai saatmiskohast vaadelda, mitte pordi omadust. Lugege olekusõna nii ja kaks lahknevat jooksu hakkavad tunduma järjekindlad, mitte vastuolulised, samal ajal kui küsimus liigub sellest, kas port on avatud, selle juurde, kes selle ees seisis.
Vastake teisele küsimusele backendis, mitte väljastpoolt. Frontend, mis võtab ühendusi vastu ja seejärel ei jõua oma upstreamini, tekitab täpselt terve teenuse välise pildi aeglase rakendusega. Ainult upstreami enda kirje eristab kahte juhtumit:
tail -n 5 /var/log/nginx/access.log
ss -ltnp 'sport = :443'Logirida näitab kliendi aadressi, mida rakendus tegelikult nägi, ja teine käsk näitab, kas porti 443 hoidv protsess on teie rakendus või miski selle ees. Kui need kaks lahknevad selles, milline aadress ühendus, vaatate te ühe päringu kahte jalga ja pilet peaks seda ütlema.
Kontrollige oma reegleid enne, kui süüdistate tunnelit
Tahtlik poliitika on kõige tavalisem põhjus, miks port vastab ühes võrgus ja mitte teises, ja see on kõige vähem huvitav saadaolev seletus. Juurdepääsureeglid on selleks, et lubada ühte allikat ja visata ülejäänud kõrvale, nii et väljundi muutumine on täpselt see sündmus, mille jaoks need kirjutati. Seetõttu ei näita VPN-i kaudu erinev olek, et teenusepakkuja kontrollib liiklust. See näitab, et teie allikaaadress on nüüd teistsugune, mis on palju väiksem väide.
Neid reegleid saab serveril lugeda, seega lugege neid, mitte ärge spekuleerige võrgu keskosa üle. Loetlege filtrireeglid, mis mainivad kumbagi aadressivahemikku, ja seejärel kontrollige, kas ühendus jõudis deemonini üldse:
nft list ruleset | grep -n -e 203.0.113 -e 198.51.100
journalctl -u sshd -n 50 | grep 203.0.113Tühi teine tulemus on informatiivne, sest deemonini ei jõudnud miski ja küsimus kuulub filtrile, turvagrupile või teele endale. Tabamus tähendab, et teenus nägi teie allikat ja valis oma vastuse, ja see otsus on tavaliselt kirjas reeglis, mida saate lugeda. Kumbki tulemus ei toeta lugu teenusepakkujast, ja mõlemat on odavam kontrollida kui paketipüük.
Lugege transporti, sertifikaati ja vastust eraldi
Kolm kihti tekitavad kolm vaatlust, ja sond, mis testib ühte neist, ei saa teistest kahest aru anda. Hoidke neid kirjes eraldi ridadena, mitte ärge voltige neid üheks otsuseks, sest iga rida ebaõnnestub omal moel ja tõrkeviis ütleb teile, kuhu järgmisena vaadata.
| 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 |
Üks käsk tekitab kolm esimest rida teenuse vastu, mida kontrollite. Pange selle väljund kirjesse skaneerimise kõrvale, mitte vestlussõnumisse:
curl -v --resolve office.example:443:203.0.113.20 https://office.example/Lugege väljundit järjekorras: kätlus vastab transpordi küsimusele, sertifikaadi subjekt vastab nime küsimusele ja vastuse keha vastab rakenduse küsimusele. Kui kätluse rida õnnestub ja vastuse rida mitte, on teil katkise upstreamiga frontend, mitte blokeeritud port. See on teine pilet kui see, mille avasite, ja seda tasub selgelt öelda.
Lõpetage, kirjutades piletisse neli fakti: allikaaadress, skaneerimise tüüp, vastanud host ja aeg. Kõik, mida hilisem võrdlus vajab, elab neis neljas, ja kes juhtumi järgmisena üle võtab, ei saa teie terminali ajalugu. Kui te ei suuda kõiki nelja täita, ei ole jooks lõppenud.