Por que Port-Share fai que todos os visitantes do sitio parezan localhost

Cada liña do rexistro de acceso mostra o mesmo enderezo de loopback, mentres a páxina carga e o certificado se valida correctamente. Nada está roto no sentido de ser inaccesible, e por iso isto sobrevive durante meses. O que se rompeu é a atribución: o backend web rexistra o enderezo do salto que reenviou a conexión, e cada decisión posterior que confiou no rexistro herdou a mesma resposta equivocada.

As comprobacións seguintes van do cable cara a dentro. Detéñase na primeira que explique o valor que ve, porque cada paso posterior supón que os anteriores xa son certos. Ningunha delas require adiviñar a configuración do front-end.

Siga as dúas conexións, non a liña do rexistro

Port-Share multiplexa dous protocolos nun único escoitador TCP. OpenVPN inspecciona os primeiros bytes dunha conexión entrante, consérvaa cando parece do seu propio protocolo e entrega calquera outra cousa a un segundo destino. Ese destino adoita ser un servidor web no mesmo host, así que o socket aceptado do servidor web ten o proceso OpenVPN como par.

ss -ltnp 'sport = :443'
ss -tnp 'dport = :8080'

O primeiro comando mostra quen posúe o escoitador público. O segundo mostra as conexións que chegan ao porto do backend, e o enderezo do seu par é o que imprimirá o rexistro de acceso. Se ese par é loopback, o rexistro é exacto e a información perdeuse unha capa antes. Renomear o campo do rexistro ou activar un módulo de IP de cliente non recuperará un enderezo que a conexión nunca levou.

Esta é a comprobación que decide todo o demais. Se o par do backend é o enderezo do navegador, compartir o porto non é o seu problema e o formato do rexistro si o é.

O reenvío de transporte non é inxección de cabeceiras

O reenviador move bytes. Non analiza HTTP, así que non pode inserir unha cabeceira nunha petición que nunca le como petición, nin pode engadir nada a un fluxo TLS que deixa pasar intacto. Un módulo que espera unha cabeceira de proxy seguirá esperando unha que ningún compoñente produce.

Dous mecanismos poden levar o enderezo orixinal, e ambos requiren acordo nos dous extremos. O protocolo PROXY antepón unha cabeceira pequena á conexión, e o backend debe estar configurado para esperala; un backend que non a espera tratará eses bytes como o inicio da petición e fallará dun xeito confuso. As cabeceiras de proxy de confianza como X-Forwarded-For funcionan cando un proxy que entende HTTP as establece e ao backend se lle di que pares poden afirmalas.

Ningún dos dous é automático, e ningún é seguro por defecto. Un backend que cre calquera cabeceira reenviada entrante permite que un cliente elixa o seu propio enderezo, o que converte unha imprecisión do rexistro nunha elusión do control de acceso. Execute a demostración unha vez nun host de probas antes de confiar en calquera cabeceira nunha ruta de produción.

curl -sS -H 'X-Forwarded-For: 127.0.0.1' https://site.example.com/health
grep -F '127.0.0.1' /var/log/nginx/access.log | tail -n 3

O directorio opcional de asignación de orixe

Compartir o porto ten un argumento de directorio opcional que rexistra unha asignación entre o enderezo de orixe orixinal e a conexión de reenvío, en plataformas onde a función está implementada. Espérase que o lado web consulte esa asignación; non é unha cabeceira e non se inxecta na petición.

Ese deseño merece coñecerse porque explica por que algúns despregamentos informan enderezos reais e outros non, cunha configuración de front-end aparentemente idéntica. A diferenza está no lado receptor, e adoita vivir nun módulo ou parche que a maioría dos servidores web empaquetados non activan por defecto. Lea a documentación do seu servidor web para coñecer o gancho exacto que ofrece e confirme que o módulo está cargado en lugar de supoñelo.

Se segue este camiño, tráteo como unha integración de dúas metades: a asignación que escribe o reenviador e a consulta que fai o backend. Verifique ambas e confirme que o directorio sobrevive a un reinicio e non medra sen límite nun escoitador ocupado.

Decida que compoñente avala o enderezo

Antes de cambiar a configuración, nomee o compoñente ao que se permite afirmar un enderezo de cliente e os compoñentes aos que se permite crelo. Unha única resposta escrita evita a deriva habitual, na que tres capas distintas confían cada unha nunha fonte distinta.

Tres deseños cobren a maioría das necesidades. Manteña separados o escoitador público e o escoitador web, de modo que o servidor web vexa pares reais e non exista problema de atribución. Poña diante un proxy inverso que entenda HTTP, termine ou analice a petición alí e déixelle establecer unha cabeceira reenviada para un backend que só confía nese proxy. Ou manteña o porto compartido e acepte que os rexistros mostran o salto, con regras de acceso escritas contra a identidade da aplicación en lugar dun enderezo.

O que non funciona é tratar un enderezo de loopback reenviado como proba de que a petición se orixinou nesta máquina. Esa inferencia é exactamente ao revés: o enderezo está presente precisamente porque un compoñente local fixo a conexión. Unha regra escrita así admite a calquera que poida alcanzar o escoitador.

Probe a regra, non a páxina

Unha páxina que carga demostra que o camiño de reenvío funciona e non di nada sobre a atribución. Probe o consumidor do enderezo: a regra de acceso, o límite de taxa, a entrada de auditoría, a consulta xeográfica.

curl -sS -o /dev/null -w '%{http_code}\n' https://site.example.com/
tail -n 5 /var/log/nginx/access.log
grep -c '' /var/log/nginx/access.log

Compare unha petición externa autorizada cos rexistros tanto do front-end como do backend e confirme que unha regra que debería denegar segue denegando e unha que debería admitir segue admitindo. Se a liña do rexistro é correcta pero a regra segue comportándose como se todos fosen locais, a regra le un campo distinto do que vostede corrixiu.

Termine escribindo a cadea de atribución nas notas de despregamento: que escoitador, que reenviador, que cabeceira ou asignación e que backend está configurado para confiar nela. A seguinte persoa que lea unha liña de rexistro necesitará as catro, e a ausencia desa nota é como o mesmo tícket se reabre un ano despois. Manteña a nota xunto á configuración e non nun fío de chat.