Per què canvien els resultats de l’escaneig de ports darrere d’una sortida VPN?
Canvieu la sortida i un port pot respondre diferent sense que el servei es mogui. Separeu l’observació del camí de l’inventari que realment necessiteu.
Executeu la mateixa comprovació de port des d’una línia d’oficina i des d’una sortida VPN, i les dues respostes poden discrepar sobre una adreça que ningú no ha canviat. Aquesta diferència ve de la ruta i de quin amfitrió ha respost, no de si el servei està actiu o aturat. Tres preguntes separen aquestes explicacions: què ha preguntat realment la sonda, quin amfitrió ha respost i què ha registrat el vostre propi servidor. Recorreu-les en aquest ordre i escriviu cada resposta abans de passar a la següent.
Repareu la sonda abans de comparar dues execucions
Una paraula d’estat només és comparable amb una altra paraula d’estat quan totes dues surten del mateix experiment. Cinc camps ho fixen: l’adreça d’origen que ha vist el costat llunyà, la destinació resolta, el port, el tipus d’escaneig i l’hora. Canvieu-ne qualsevol i haureu fet un segon experiment en lloc de mesurar el primer dues vegades.
Comproveu l’origen abans que res, perquè un client VPN pot estar actiu mentre el trànsit encara surt per la interfície física. Pregunteu al costat llunyà què veu i després pregunteu al nucli quina interfície ha triat:
curl -s https://ifconfig.me
ip route get 203.0.113.20Dues adreces en xarxes diferents volen dir que l’explicació ja la teniu a la mà, i la resta de comprovacions només la confirmaran. Quan coincideixin, captureu la sonda amb el flag de motiu activat, perquè l’estat torni lligat a una explicació en lloc de quedar-se sol com una paraula nua. El tipus d’escaneig també pertany a aquest registre, perquè descriu què s’ha demanat i no què ha tornat. Un estat sense origen, sense mètode i sense marca de temps no es pot comparar amb res:
nmap -sT -p 443,8443 --reason 203.0.113.20Guardeu aquesta sortida al costat del registre i no en un buffer de desplaçament que la propera persona no pugui veure. Dos escanejos honestos que discrepen només són una discussió quan ningú no ha escrit les condicions. Amb les condicions fixades, o els resultats coincideixen i la qüestió queda tancada, o difereixen i la diferència és un fet sobre el camí.
Esbrineu quin amfitrió ha acabat l’encaixada de mans
Una encaixada de mans completada demostra que algun amfitrió l’ha completada, i aquest amfitrió no cal que sigui el procés que teniu al cap. Un balancejador de càrrega, un proxy invers o un proxy SYN poden respondre abans que el servidor real hi intervingui, cosa que és disseny habitual i no un símptoma. Un certificat vàlid per al nom esperat tampoc no ho acota, perquè un certificat descriu una relació de servei i no diu res sobre quina màquina ha acabat la connexió.
La referència d’estats de port de Nmap ho considera bàsic: un estat registra què podia observar una sonda des d’on s’ha enviat, no una propietat del port. Llegiu una paraula d’estat així i dues execucions que discrepaven comencen a semblar coherents en lloc de contradictòries, mentre la pregunta passa de si el port és obert a qui hi havia al davant.
Responeu la segona pregunta al backend i no des de fora. Un frontend que accepta connexions i després no arriba al seu upstream produeix exactament la imatge externa d’un servei sa amb una aplicació lenta. Només el registre propi de l’upstream separa els dos casos:
tail -n 5 /var/log/nginx/access.log
ss -ltnp 'sport = :443'La línia de registre mostra l’adreça de client que l’aplicació ha vist realment, i la segona comanda mostra si el procés que té el port 443 és la vostra aplicació o alguna cosa al davant. Si les dues discrepen sobre quina adreça s’ha connectat, esteu mirant dues cames d’una sola petició i el tiquet ho hauria de dir.
Comproveu les vostres pròpies regles abans de culpar el túnel
Una política deliberada és el motiu més habitual que un port respongui en una xarxa i no en una altra, i és l’explicació menys interessant disponible. Les regles d’accés existeixen per permetre un origen i descartar la resta, així que un canvi de sortida és exactament l’esdeveniment per al qual es van escriure. Per tant, un estat diferent a través d’una VPN no demostra que el proveïdor inspecti el trànsit. Demostra que la vostra adreça d’origen ara és diferent, que és una afirmació molt més petita.
Aquestes regles es poden llegir al servidor, així que llegiu-les en lloc d’especular sobre el mig de la xarxa. Llisteu les regles de filtre que esmenten qualsevol dels dos rangs d’adreces i després comproveu si la connexió ha arribat al dimoni:
nft list ruleset | grep -n -e 203.0.113 -e 198.51.100
journalctl -u sshd -n 50 | grep 203.0.113Un segon resultat buit és informatiu, perquè no ha arribat res al dimoni i la pregunta pertany a un filtre, a un grup de seguretat o al mateix camí. Un encert vol dir que el servei ha vist el vostre origen i ha triat la seva resposta, i aquesta decisió normalment està escrita en una regla que podeu llegir. Cap dels dos resultats no sosté una història sobre el proveïdor, i tots dos són més barats de comprovar que una captura de paquets.
Llegiu transport, certificat i resposta per separat
Tres capes produeixen tres observacions, i una sonda que prova una d’elles no pot informar de les altres dues. Manteniu-les com a línies separades al registre en lloc de doblegar-les en un sol veredicte, perquè cada línia falla a la seva manera i el mode de fallada us diu on mirar després.
| 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 |
Una comanda produeix les tres primeres files contra un servei que controleu. Poseu la seva sortida al registre al costat de l’escaneig i no en un missatge de xat:
curl -v --resolve office.example:443:203.0.113.20 https://office.example/Llegiu la sortida per ordre: l’encaixada de mans respon la pregunta de transport, el subjecte del certificat respon la pregunta del nom i el cos de la resposta respon la pregunta de l’aplicació. Quan la línia d’encaixada de mans té èxit i la de resposta no, teniu un frontend amb un upstream trencat i no un port bloquejat. Aquest és un tiquet diferent del que heu obert, i val la pena dir-ho clarament.
Acabeu escrivint quatre fets al tiquet: adreça d’origen, tipus d’escaneig, l’amfitrió que ha respost i l’hora. Tot el que una comparació posterior necessita viu en aquests quatre, i qui reculli el cas després no tindrà l’historial del vostre terminal. Si no podeu omplir-los tots quatre, l’execució no ha acabat.