Zakaj se rezultati skeniranja vrat spreminjajo za izhodom VPN?

Zaženite isto preverjanje vrat iz pisarniške linije in iz izhoda VPN, pa se lahko oba odgovora razhajata glede naslova, ki ga ni nihče spremenil. Ta vrzel prihaja s poti in od tega, kateri gostitelj je odgovoril, ne od tega, ali storitev deluje. Tri vprašanja ločujejo te razlage: kaj je sonda v resnici vprašala, kateri gostitelj je odgovoril in kaj je zabeležil vaš lastni strežnik. Pojdite skoznje v tem vrstnem redu in vsak odgovor zapišite, preden se premaknete na naslednjega.

Popravite sondo, preden primerjate dva zagona

Besedo stanja je mogoče primerjati z drugo besedo stanja le, kadar obe izhajata iz istega poskusa. Pet polj to določa: izvorni naslov, ki ga je videla oddaljena stran, razrešeni cilj, vrata, vrsta skeniranja in čas. Spremenite katerega koli od njih in izvedli ste drugi poskus, namesto da bi prvega izmerili dvakrat.

Preverite vir pred vsem drugim, ker je odjemalec VPN lahko vklopljen, medtem ko promet še vedno odhaja skozi fizični vmesnik. Vprašajte oddaljeno stran, kaj vidi, nato vprašajte jedro, kateri vmesnik je izbralo:

curl -s https://ifconfig.me
ip route get 203.0.113.20

Dva naslova v različnih omrežjih pomenita, da je razlaga že v roki, in preostale kontrole jo bodo le potrdile. Ko se ujemata, zajemite sondo z vključeno zastavico razloga, da se stanje vrne povezano z razlago, namesto da bi stalo samo kot gola beseda. Vrsta skeniranja prav tako spada v ta zapis, ker opisuje, kaj je bilo vprašano, in ne, kaj se je vrnilo. Stanja brez vira, brez metode in brez časovnega žiga ni mogoče primerjati z ničimer:

nmap -sT -p 443,8443 --reason 203.0.113.20

Hranite ta izhod ob zapisu in ne v medpomnilniku za drsenje, ki ga naslednja oseba ne more videti. Dve pošteni skeniranji, ki se razhajata, sta spor le, kadar nihče ni zapisal pogojev. Ko so pogoji določeni, se bodisi rezultati ujemajo in je vprašanje zaprto, bodisi se razlikujejo in razlika je dejstvo o poti.

Ugotovite, kateri gostitelj je dokončal rokovanje

Dokončano rokovanje dokazuje, da ga je dokončal neki gostitelj, in ta gostitelj ni nujno proces, ki ga imate v mislih. Uravnavalnik obremenitve, obratni posrednik ali posrednik SYN lahko odgovorijo, preden je vključen pravi strežnik, kar je običajna zasnova in ne simptom. Veljavno potrdilo za pričakovano ime tega prav tako ne zoži, ker potrdilo opisuje razmerje storitve in ne pove ničesar o tem, kateri stroj je končal povezavo.

Referenca Nmap za stanja vrat to obravnava kot osnovo: stanje zabeleži, kaj je sonda lahko opazovala s kraja pošiljanja, ne lastnosti vrat. Berite besedo stanja tako in dva zagona, ki se nista ujemala, se začneta videti skladna in ne protislovna, medtem ko se vprašanje premakne s tega, ali so vrata odprta, na to, kdo je stal pred njimi.

Odgovorite na drugo vprašanje v backendu in ne od zunaj. Frontend, ki sprejema povezave in nato ne doseže svojega upstreama, ustvari natanko zunanjo podobo zdrave storitve s počasno aplikacijo. Samo lastni zapis upstreama loči oba primera:

tail -n 5 /var/log/nginx/access.log
ss -ltnp 'sport = :443'

Vrstica dnevnika prikazuje naslov odjemalca, ki ga je aplikacija resnično videla, drugi ukaz pa prikazuje, ali je proces, ki drži vrata 443, vaša aplikacija ali nekaj pred njo. Če se ta dva razhajata glede tega, kateri naslov se je povezal, gledate dve nogi ene zahteve in vstopnica bi morala to povedati.

Preverite svoja pravila, preden obtožite tunel

Naklepna politika je najpogostejši razlog, da vrata odgovorijo v enem omrežju in ne v drugem, in je najmanj zanimiva razlaga, ki je na voljo. Pravila dostopa obstajajo zato, da dovolijo en vir in zavržejo ostale, zato je sprememba izhoda natanko tisti dogodek, za katerega so bila napisana. Zato drugačno stanje prek VPN ne kaže, da ponudnik pregleduje promet. Kaže, da je vaš izvorni naslov zdaj drugačen, kar je veliko manjša trditev.

Ta pravila je mogoče brati na strežniku, zato jih preberite, namesto da ugibate o sredini omrežja. Naštejte pravila filtra, ki omenjajo katero koli od dveh območij naslovov, nato preverite, ali je povezava sploh prišla do demona:

nft list ruleset | grep -n -e 203.0.113 -e 198.51.100
journalctl -u sshd -n 50 | grep 203.0.113

Prazen drugi rezultat je informativen, ker nič ni prišlo do demona in vprašanje spada k filtru, varnostni skupini ali sami poti. Zadetek pomeni, da je storitev videla vaš vir in izbrala svoj odgovor, in ta odločitev je običajno zapisana v pravilu, ki ga lahko preberete. Noben rezultat ne podpira zgodbe o ponudniku in oba sta cenejša za preverjanje kot zajem paketov.

Berite transport, potrdilo in odgovor ločeno

Tri plasti ustvarijo tri opažanja, in sonda, ki preizkuša eno od njih, ne more poročati o drugih dveh. Imajte jih kot ločene vrstice v zapisu, namesto da jih zložite v eno sodbo, ker vsaka vrstica odpove na svoj način in način odpovedi vam pove, kam pogledati naslednjič.

En ukaz ustvari prve tri vrstice proti storitvi, ki jo nadzirate. Njegov izhod dajte v zapis ob skeniranju in ne v klepetalno sporočilo:

curl -v --resolve office.example:443:203.0.113.20 https://office.example/

Berite izhod po vrsti: rokovanje odgovori na vprašanje transporta, predmet potrdila na vprašanje imena in telo odgovora na vprašanje aplikacije. Ko vrstica rokovanja uspe in vrstica odgovora ne, imate frontend z zlomljenim upstreamom in ne blokirana vrata. To je drugačna vstopnica od tiste, ki ste jo odprli, in vredno je to povedati naravnost.

Končajte tako, da v vstopnico zapišete štiri dejstva: izvorni naslov, vrsto skeniranja, gostitelja, ki je odgovoril, in čas. Vse, kar poznejša primerjava potrebuje, živi v teh štirih, in kdor prevzame primer naslednji, ne bo imel zgodovine vašega terminala. Če ne morete izpolniti vseh štirih, zagon ni končan.