De ce se schimbă rezultatele scanării porturilor în spatele unei ieșiri VPN?
Schimbați ieșirea și un port poate răspunde altfel fără ca serviciul să se miște. Separați observația traseului de inventarul de care aveți cu adevărat nevoie.
Rulați aceeași verificare de port dintr-o linie de birou și dintr-o ieșire VPN, iar cele două răspunsuri pot să nu fie de acord cu privire la o adresă pe care nimeni nu a schimbat-o. Acea diferență vine din traseu și din ce gazdă a răspuns, nu din faptul că serviciul este pornit sau oprit. Trei întrebări separă aceste explicații: ce a întrebat sonda de fapt, ce gazdă a răspuns și ce a înregistrat propriul server. Parcurgeți-le în această ordine și notați fiecare răspuns înainte de a trece la următorul.
Reparați sonda înainte de a compara două rulări
Un cuvânt de stare este comparabil cu alt cuvânt de stare doar când ambele provin din același experiment. Cinci câmpuri fixează asta: adresa sursă văzută de partea îndepărtată, destinația rezolvată, portul, tipul de scanare și ora. Schimbați oricare dintre ele și ați făcut un al doilea experiment, în loc să îl măsurați pe primul de două ori.
Verificați sursa înainte de orice altceva, pentru că un client VPN poate fi pornit în timp ce traficul iese încă prin interfața fizică. Întrebați partea îndepărtată ce vede, apoi întrebați nucleul ce interfață a ales:
curl -s https://ifconfig.me
ip route get 203.0.113.20Două adrese în rețele diferite înseamnă că explicația este deja la îndemână, iar restul acestor verificări o vor confirma doar. Când sunt de acord, capturați sonda cu indicatorul de motiv activat, astfel încât starea să revină legată de o explicație în loc să stea singură ca un cuvânt gol. Tipul de scanare aparține și el acelei înregistrări, pentru că descrie ce s-a cerut, nu ce a revenit. O stare fără sursă, fără metodă și fără marcă temporală nu poate fi comparată cu nimic:
nmap -sT -p 443,8443 --reason 203.0.113.20Păstrați acea ieșire lângă înregistrare și nu într-un buffer de derulare pe care următoarea persoană nu îl poate vedea. Două scanări oneste care nu sunt de acord sunt o dispută doar când nimeni nu a notat condițiile. Cu condițiile fixate, fie rezultatele coincid și întrebarea este închisă, fie diferă și diferența este un fapt despre traseu.
Aflați ce gazdă a terminat strângerea de mână
O strângere de mână finalizată dovedește că o gazdă a finalizat-o, iar acea gazdă nu trebuie să fie procesul la care vă gândiți. Un echilibrator de sarcină, un proxy invers sau un proxy SYN pot răspunde înainte ca serverul real să fie implicat, ceea ce este proiectare obișnuită, nu un simptom. Un certificat valid pentru numele așteptat nu restrânge nici el acest lucru, pentru că un certificat descrie o relație de serviciu și nu spune nimic despre ce mașină a încheiat conexiunea.
Referința Nmap pentru stările porturilor tratează acest lucru ca elementar: o stare înregistrează ce a putut observa o sondă din locul de unde a fost trimisă, nu o proprietate a portului. Citiți un cuvânt de stare astfel și două rulări care nu erau de acord încep să pară consecvente în loc de contradictorii, în timp ce întrebarea se mută de la dacă portul este deschis la cine stătea în fața lui.
Răspundeți la a doua întrebare în backend și nu din exterior. Un frontend care acceptă conexiuni și apoi nu ajunge la upstream-ul său produce exact imaginea externă a unui serviciu sănătos cu o aplicație lentă. Doar înregistrarea upstream-ului însuși separă cele două cazuri:
tail -n 5 /var/log/nginx/access.log
ss -ltnp 'sport = :443'Linia de jurnal arată adresa de client pe care aplicația a văzut-o cu adevărat, iar a doua comandă arată dacă procesul care ține portul 443 este aplicația dumneavoastră sau ceva din fața ei. Dacă cele două nu sunt de acord cu privire la adresa care s-a conectat, vă uitați la două picioare ale aceleiași cereri și biletul ar trebui să spună asta.
Verificați propriile reguli înainte de a da vina pe tunel
Politica deliberată este cel mai frecvent motiv pentru care un port răspunde într-o rețea și nu în alta, și este cea mai puțin interesantă explicație disponibilă. Regulile de acces există pentru a permite o sursă și a elimina restul, așa că o schimbare a ieșirii este exact evenimentul pentru care au fost scrise. De aceea o stare diferită prin VPN nu arată că furnizorul inspectează traficul. Arată că adresa dumneavoastră sursă este acum diferită, ceea ce este o afirmație mult mai mică.
Acele reguli pot fi citite pe server, așa că citiți-le în loc să speculați despre mijlocul rețelei. Enumerați regulile de filtrare care menționează oricare dintre cele două intervale de adrese, apoi verificați dacă conexiunea a ajuns măcar la daemon:
nft list ruleset | grep -n -e 203.0.113 -e 198.51.100
journalctl -u sshd -n 50 | grep 203.0.113Un al doilea rezultat gol este informativ, pentru că nimic nu a ajuns la daemon și întrebarea aparține unui filtru, unui grup de securitate sau traseului însuși. O potrivire înseamnă că serviciul v-a văzut sursa și și-a ales răspunsul, iar acea decizie este de obicei scrisă într-o regulă pe care o puteți citi. Niciunul dintre rezultate nu susține o poveste despre furnizor, și ambele sunt mai ieftin de verificat decât o captură de pachete.
Citiți transportul, certificatul și răspunsul separat
Trei straturi produc trei observații, iar o sondă care testează unul dintre ele nu poate raporta despre celelalte două. Păstrați-le ca linii separate în înregistrare în loc să le pliați într-un singur verdict, pentru că fiecare linie eșuează în felul ei, iar modul de eșec vă spune unde să priviți mai departe.
| 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 |
O singură comandă produce primele trei rânduri împotriva unui serviciu pe care îl controlați. Puneți ieșirea ei în înregistrare lângă scanare, nu într-un mesaj de chat:
curl -v --resolve office.example:443:203.0.113.20 https://office.example/Citiți ieșirea în ordine: strângerea de mână răspunde la întrebarea despre transport, subiectul certificatului la întrebarea despre nume, iar corpul răspunsului la întrebarea despre aplicație. Când linia strângerii de mână reușește și cea a răspunsului nu, aveți un frontend cu upstream-ul rupt, nu un port blocat. Acesta este un bilet diferit de cel pe care l-ați deschis, și merită spus clar.
Încheiați scriind patru fapte în bilet: adresa sursă, tipul de scanare, gazda care a răspuns și ora. Tot ce are nevoie o comparație ulterioară trăiește în acele patru, iar cine preia cazul următor nu va avea istoricul terminalului dumneavoastră. Dacă nu puteți completa toate patru, rularea nu s-a terminat.