Miért jeleníti meg a Port-Share az összes weboldal-látogatót localhostként

A hozzáférési napló minden sora ugyanazt a loopback címet mutatja, miközben az oldal betöltődik és a tanúsítvány helyesen ellenőrződik. Semmi sem romlott el az elérhetetlenség értelmében, és éppen ezért marad fenn ez hónapokig. Ami elromlott, az a hozzárendelés: a webes háttérrendszer annak az ugrásnak a címét rögzíti, amely továbbította a kapcsolatot, és minden későbbi döntés, amely a naplóban bízott, ugyanazt a rossz választ örökölte.

Az alábbi ellenőrzések a kábeltől befelé haladnak. Álljon meg az elsőnél, amely megmagyarázza a látott értéket, mert minden későbbi lépés feltételezi, hogy az előzőek már igazak. Egyik sem kívánja meg a front-end konfigurációjának kitalálását.

Kövesse a két kapcsolatot, ne a naplósort

A Port-Share két protokollt multiplexel egyetlen TCP-figyelőn. Az OpenVPN megvizsgálja a bejövő kapcsolat első bájtjait, megtartja, ha a saját protokolljára hasonlít, és minden mást egy második célpontnak ad át. Ez a célpont rendszerint egy webkiszolgáló ugyanazon a gazdagépen, így a webkiszolgáló elfogadott socketjének partnere az OpenVPN-folyamat.

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

Az első parancs megmutatja, kié a nyilvános figyelő. A második a háttérrendszer portjára érkező kapcsolatokat mutatja, és ezek partnercíme az, amelyet a hozzáférési napló kiír. Ha ez a partner loopback, a napló pontos, és az információ egy réteggel korábban elveszett. A naplómező átnevezése vagy egy ügyfél-IP modul engedélyezése nem hoz vissza olyan címet, amelyet a kapcsolat soha nem hordozott.

Ez az az ellenőrzés, amely minden mást eldönt. Ha a háttérrendszer partnere a böngésző címe, akkor a portmegosztás nem az Ön problémája, hanem a napló formátuma.

A szállítási továbbítás nem fejléc-injektálás

A továbbító bájtokat mozgat. Nem elemzi a HTTP-t, ezért nem tud fejlécet beszúrni olyan kérésbe, amelyet soha nem kérésként olvas, és nem tud hozzáadni semmit egy TLS-folyamhoz, amelyet érintetlenül enged át. A proxy fejlécet váró modul továbbra is olyasmire vár, amelyet egyetlen összetevő sem állít elő.

Két mechanizmus hordozhatja az eredeti címet, és mindkettő megegyezést igényel mindkét oldalon. A PROXY protokoll egy kis fejlécet illeszt a kapcsolat elé, és a háttérrendszert be kell állítani, hogy számítson rá; az a háttérrendszer, amely nem számít rá, ezeket a bájtokat a kérés kezdetének tekinti, és zavaró módon hibázik. A megbízható proxy fejlécek, például a X-Forwarded-For, akkor működnek, ha egy HTTP-t értő proxy beállítja őket, és a háttérrendszernek megmondják, mely partnerek állíthatják ezt.

Egyik sem automatikus, és egyik sem biztonságos alapértelmezés szerint. Az a háttérrendszer, amely minden bejövő továbbított fejlécnek hisz, engedi az ügyfélnek a saját címét választani, ami a napló pontatlanságát a hozzáférés-vezérlés megkerülésévé változtatja. Futtassa a bemutatót egyszer egy tesztgazdagépen, mielőtt bármely fejlécben megbízik éles útvonalon.

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

Az opcionális forrásleképező könyvtár

A portmegosztásnak van egy opcionális könyvtárargumentuma, amely az eredeti forráscím és a továbbító kapcsolat közötti leképezést rögzíti azokon a platformokon, ahol a funkció meg van valósítva. Elvárás, hogy a webes oldal ezt a leképezést megnézze; ez nem fejléc, és nem injektálódik a kérésbe.

Érdemes ismerni ezt a tervezést, mert megmagyarázza, miért jelentenek be egyes telepítések valódi címeket, mások pedig nem, látszólag azonos front-end konfiguráció mellett. A különbség a fogadó oldalon van, és rendszerint egy olyan modulban vagy javításban él, amelyet a legtöbb csomagolt webkiszolgáló alapértelmezés szerint nem engedélyez. Olvassa el a webkiszolgáló dokumentációjában, milyen pontos kampót kínál, és erősítse meg, hogy a modul be van töltve, ahelyett hogy feltételezné.

Ha ezt az utat választja, két félből álló integrációként kezelje: a továbbító által írt leképezés és a háttérrendszer által végzett keresés. Mindkettőt ellenőrizze, és erősítse meg, hogy a könyvtár túléli az újraindítást, és forgalmas figyelőn nem nő korlátlanul.

Döntse el, melyik összetevő kezeskedik a címért

A konfiguráció módosítása előtt nevezze meg azt az összetevőt, amely jogosult ügyfélcímet állítani, és azokat az összetevőket, amelyek jogosultak neki hinni. Egyetlen leírt válasz megakadályozza a szokásos elsodródást, amikor három különböző réteg mindegyike más forrásban bízik.

Három terv lefedi a legtöbb igényt. Tartsa külön a nyilvános figyelőt és a webfigyelőt, hogy a webkiszolgáló valódi partnereket lásson, és ne legyen hozzárendelési probléma. Helyezzen elé egy HTTP-t értő fordított proxyt, ott fejezze be vagy elemezze a kérést, és engedje, hogy továbbított fejlécet állítson be egy olyan háttérrendszer számára, amely csak ebben a proxyban bízik. Vagy tartsa meg a portmegosztást, és fogadja el, hogy a naplók az ugrást mutatják, a hozzáférési szabályok pedig az alkalmazás identitása ellen íródnak, nem egy cím ellen.

Ami nem működik, az a továbbított loopback cím bizonyítékként kezelése arra, hogy a kérés ezen a gépen keletkezett. Ez a következtetés pontosan fordított: a cím éppen azért van jelen, mert egy helyi összetevő hozta létre a kapcsolatot. Az így megírt szabály mindenkit beenged, aki eléri a figyelőt.

A szabályt tesztelje, ne az oldalt

A betöltődő oldal bizonyítja, hogy a továbbítási útvonal működik, és semmit sem mond a hozzárendelésről. Tesztelje a cím fogyasztóját: a hozzáférési szabályt, a sebességkorlátot, az audit bejegyzést, a földrajzi keresést.

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

Hasonlítsa össze egy engedélyezett külső kérést a front-end és a háttérrendszer feljegyzéseivel is, és erősítse meg, hogy a tiltania kellő szabály továbbra is tilt, és az engedélyeznie kellő továbbra is engedélyez. Ha a naplósor helyes, de a szabály továbbra is úgy viselkedik, mintha mindenki helyi lenne, a szabály más mezőt olvas, mint amelyet javított.

Fejezze be azzal, hogy a hozzárendelési láncot beírja a telepítési jegyzetekbe: melyik figyelő, melyik továbbító, melyik fejléc vagy leképezés, és melyik háttérrendszer van beállítva, hogy megbízzon benne. A következő embernek, aki naplósort olvas, mind a négyre szüksége lesz, és e jegyzet hiánya az, amiért ugyanaz a jegy egy év múlva újra megnyílik. Tartsa a konfiguráció mellett, ne egy csevegőszálban.