Por que cambian os resultados da exploración de portos tras unha saída VPN?

Execute a mesma comprobación de porto desde unha liña de oficina e desde unha saída VPN, e as dúas respostas poden discrepar sobre un enderezo que ninguén cambiou. Esa fenda vén da ruta e de que host respondeu, non de se o servizo está activo ou caído. Tres preguntas separan esas explicacións: que preguntou realmente a sonda, que host respondeu e que rexistrou o seu propio servidor. Percórraas nesa orde e anote cada resposta antes de pasar á seguinte.

Corrixa a sonda antes de comparar dúas execucións

Unha palabra de estado só é comparable con outra palabra de estado cando ambas saíron do mesmo experimento. Cinco campos fíxano: o enderezo de orixe que viu o lado remoto, o destino resolvido, o porto, o tipo de exploración e a hora. Cambie calquera deles e terá feito un segundo experimento en lugar de medir o primeiro dúas veces.

Comprobe a orixe antes que nada, porque un cliente VPN pode estar activo mentres o tráfico aínda sae pola interface física. Pregunte ao lado remoto que ve e despois pregunte ao núcleo que interface escolleu:

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

Dous enderezos en redes distintas significan que a explicación xa está na man, e o resto destas comprobacións só a confirmarán. Cando coincidan, capture a sonda co indicador de motivo activado, para que o estado volva ligado a unha explicación en lugar de quedar só como unha palabra espida. O tipo de exploración tamén pertence a ese rexistro, porque describe que se preguntou e non que volveu. Un estado sen orixe, sen método e sen marca de tempo non se pode comparar con nada:

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

Garde esa saída xunto ao rexistro e non nun búfer de desprazamento que a seguinte persoa non poida ver. Dúas exploracións honestas que discrepan só son unha discusión cando ninguén escribiu as condicións. Coas condicións fixadas, ou os resultados coinciden e a cuestión queda pechada, ou difiren e a diferenza é un feito sobre a ruta.

Averigüe que host terminou o aperto de mans

Un aperto de mans completado demostra que algún host o completou, e ese host non ten por que ser o proceso que ten en mente. Un balanceador de carga, un proxy inverso ou un proxy SYN poden responder antes de que interveña o servidor real, o cal é deseño habitual e non un síntoma. Un certificado válido para o nome esperado tampouco o acouta, porque un certificado describe unha relación de servizo e non di nada sobre que máquina terminou a conexión.

A referencia de estados de porto de Nmap considérao básico: un estado rexistra o que unha sonda puido observar desde onde se enviou, non unha propiedade do porto. Lea unha palabra de estado así e dúas execucións que discrepaban empezan a parecer coherentes en lugar de contradictorias, mentres a pregunta pasa de se o porto está aberto a quen estaba diante del.

Responda a segunda pregunta no backend e non desde fóra. Un frontend que acepta conexións e despois non chega ao seu upstream produce exactamente a imaxe externa dun servizo san cunha aplicación lenta. Só o rexistro propio do upstream separa os dous casos:

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

A liña do rexistro mostra o enderezo de cliente que a aplicación viu realmente, e o segundo comando mostra se o proceso que mantén o porto 443 é a súa aplicación ou algo diante dela. Se os dous discrepan sobre que enderezo se conectou, está a mirar dúas pernas dunha mesma petición e o tícket debería dicilo.

Comprobe as súas propias regras antes de culpar o túnel

A política deliberada é a razón máis común de que un porto responda nunha rede e non noutra, e é a explicación menos interesante dispoñible. As regras de acceso existen para permitir unha orixe e descartar o resto, así que un cambio de saída é exactamente o suceso para o que se escribiron. Por iso un estado distinto a través dunha VPN non demostra que o provedor inspeccione o tráfico. Demostra que o seu enderezo de orixe agora é distinto, o cal é unha afirmación moito menor.

Esas regras pódense ler no servidor, así que léaas en lugar de especular sobre o medio da rede. Enumere as regras de filtro que mencionen calquera dos dous rangos de enderezos e despois comprobe se a conexión chegou sequera ao daemon:

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

Un segundo resultado baleiro é informativo, porque nada chegou ao daemon e a pregunta pertence a un filtro, a un grupo de seguridade ou á propia ruta. Un acerto significa que o servizo viu a súa orixe e escolleu a súa resposta, e esa decisión adoita estar escrita nunha regra que pode ler. Ningún dos dous resultados sostén unha historia sobre o provedor, e ambos son máis baratos de comprobar que unha captura de paquetes.

Lea transporte, certificado e resposta por separado

Tres capas producen tres observacións, e unha sonda que proba unha delas non pode informar sobre as outras dúas. Mantéñaas como liñas separadas no rexistro en lugar de pegalas nun único veredicto, porque cada liña falla á súa maneira e o modo de fallo dille onde mirar despois.

Un só comando produce as tres primeiras filas contra un servizo que vostede controla. Poña a súa saída no rexistro xunto á exploración e non nunha mensaxe de chat:

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

Lea a saída en orde: o aperto de mans responde a pregunta de transporte, o suxeito do certificado responde a pregunta do nome e o corpo da resposta responde a pregunta da aplicación. Cando a liña do aperto de mans ten éxito e a de resposta non, ten un frontend cun upstream roto e non un porto bloqueado. Ese é un tícket distinto do que abriu, e paga a pena dicilo con claridade.

Remate escribindo catro feitos no tícket: enderezo de orixe, tipo de exploración, o host que respondeu e a hora. Todo o que unha comparación posterior necesita vive neses catro, e quen retome o caso despois non terá o historial do seu terminal. Se non pode encher os catro, a execución non rematou.