Per què Port-Share fa que tots els visitants del web semblin localhost

Cada línia del registre d'accés mostra la mateixa adreça de loopback, mentre la pàgina es carrega i el certificat es valida correctament. No hi ha res trencat en el sentit de ser inaccessible, i per això aquest cas sobreviu durant mesos. El que s'ha trencat és l'atribució: el backend web enregistra l'adreça del salt que va reenviar la connexió, i cada decisió posterior que va confiar en el registre va heretar la mateixa resposta equivocada.

Les comprovacions següents van del cable cap endins. Atureu-vos a la primera que expliqui el valor que veieu, perquè cada pas posterior assumeix que els anteriors ja són certs. Cap d'elles no requereix endevinar la configuració del front-end.

Seguiu les dues connexions, no la línia del registre

Port-Share multiplexa dos protocols en un sol oient TCP. OpenVPN inspecciona els primers bytes d'una connexió entrant, la conserva quan sembla del seu propi protocol i lliura qualsevol altra cosa a una segona destinació. Aquesta destinació és normalment un servidor web al mateix host, de manera que el sòcol acceptat del servidor web té el procés OpenVPN com a parell.

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

La primera ordre mostra qui posseeix l'oient públic. La segona mostra les connexions que arriben al port del backend, i l'adreça del seu parell és la que imprimirà el registre d'accés. Si aquest parell és loopback, el registre és exacte i la informació es va perdre una capa abans. Canviar el nom del camp del registre o activar un mòdul d'IP de client no recuperarà una adreça que la connexió mai no va portar.

Aquesta és la comprovació que decideix tota la resta. Si el parell del backend és l'adreça del navegador, compartir el port no és el vostre problema i el format del registre sí que ho és.

El reenviament de transport no és injectar capçaleres

El reenviador mou bytes. No analitza HTTP, així que no pot inserir una capçalera en una petició que mai no llegeix com a petició, ni pot afegir res a un flux TLS que deixa passar intacte. Un mòdul que espera una capçalera de proxy continuarà esperant-ne una que cap component no produeix.

Dos mecanismes poden portar l'adreça original, i tots dos requereixen acord a les dues bandes. El protocol PROXY afegeix una capçalera petita a l'inici de la connexió, i el backend ha d'estar configurat per esperar-la; un backend que no l'espera tractarà aquests bytes com l'inici de la petició i fallarà d'una manera confusa. Les capçaleres de proxy de confiança com X-Forwarded-For funcionen quan un proxy que entén HTTP les defineix i al backend se li diu quins parells poden afirmar-les.

Cap de les dues no és automàtica i cap no és segura per defecte. Un backend que creu qualsevol capçalera reenviada entrant permet al client triar la seva pròpia adreça, cosa que converteix una imprecisió del registre en un salt de control d'accés. Executeu la demostració una vegada en un host d'assaig abans de confiar en qualsevol capçalera en un camí de producció.

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

El directori opcional de mapatge d'orígens

Compartir el port té un argument de directori opcional que enregistra un mapatge entre l'adreça d'origen original i la connexió de reenviament, en plataformes on la funció està implementada. S'espera que el costat web consulti aquest mapatge; no és una capçalera i no s'injecta a la petició.

Val la pena conèixer aquest disseny perquè explica per què alguns desplegaments informen d'adreces reals i d'altres no, amb una configuració de front-end aparentment idèntica. La diferència és al costat receptor i normalment viu en un mòdul o pedaç que la majoria de servidors web empaquetats no activen per defecte. Llegiu la documentació del vostre servidor web per saber quin ganxo exacte ofereix i confirmeu que el mòdul està carregat en lloc de suposar-ho.

Si seguiu aquest camí, tracteu-ho com una integració de dues meitats: el mapatge que escriu el reenviador i la consulta que fa el backend. Verifiqueu tots dos i confirmeu que el directori sobreviu a un reinici i que no creix sense límit en un oient ocupat.

Decidiu quin component avala l'adreça

Abans de canviar la configuració, anomeneu el component que pot afirmar una adreça de client i els components que poden creure-la. Una única resposta escrita evita la deriva habitual, en què tres capes diferents confien cadascuna en una font diferent.

Tres dissenys cobreixen la majoria de necessitats. Manteniu l'oient públic i l'oient web separats, de manera que el servidor web vegi parells reals i no hi hagi cap problema d'atribució. Poseu al davant un proxy invers que entengui HTTP, acabeu o analitzeu la petició allà i deixeu-lo definir una capçalera reenviada per a un backend que només confia en aquest proxy. O manteniu el port compartit i accepteu que els registres mostren el salt, amb regles d'accés escrites contra la identitat de l'aplicació en lloc d'una adreça.

El que no funciona és tractar una adreça de loopback reenviada com a prova que la petició es va originar en aquesta màquina. Aquesta inferència és exactament al revés: l'adreça hi és precisament perquè un component local va fer la connexió. Una regla escrita així admet qualsevol que pugui arribar a l'oient.

Proveu la regla, no la pàgina

Una pàgina que es carrega demostra que el camí de reenviament funciona i no diu res sobre l'atribució. Proveu el consumidor de l'adreça: la regla d'accés, el límit de taxa, l'entrada d'auditoria, la consulta geogrà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

Compareu una petició externa autoritzada amb els registres tant del front-end com del backend i confirmeu que una regla que hauria de denegar encara denega i una que hauria d'admetre encara admet. Si la línia del registre és correcta però la regla encara es comporta com si tothom fos local, la regla llegeix un camp diferent del que heu corregit.

Acabeu escrivint la cadena d'atribució a les notes de desplegament: quin oient, quin reenviador, quina capçalera o mapatge i quin backend està configurat per confiar-hi. La propera persona que llegeixi una línia de registre necessitarà les quatre coses, i l'absència d'aquesta nota és com el mateix tiquet es reobre un any després. Manteniu-la al costat de la configuració i no en un fil de xat.