Mit árul el valójában a PHP REMOTE_ADDR-je egy VPN mögött
Ez egy érték, amelyet a webkiszolgáló adott, nem bepillantás az alagútba. Járja végig a kérés útját, ellenőrizze, ki írhatja át, és tartsa az identitást az alkalmazásban.
Valaki azt kérdezi, miért jelenik meg egy VPN-felhasználó az alkalmazásnaplóban a gatewayhez tartozó címmel, vagy olyan címmel, amely ebéd után megváltozott. A válasz azzal kezdődik, mi ez az érték: egy bejegyzés, amelyet a webkiszolgáló tett a kérés környezetébe. Nem az alagútba irányuló lekérdezés, nem tanúsítvány-identitás, és nem ígéret arra, hogy a szám egyetlen személyhez tartozik. Ha bármelyiknek olvassuk, magabiztos válaszokat kapunk, amelyek különböző módokon tévesek.
Az érték a kiszolgálótól jön, nem az alagútból
A PHP a kérés környezetét attól kapja, ami a szkriptet futtatta. A PHP kiszolgálóváltozók referenciája ezeket a bejegyzéseket a webkiszolgáló által létrehozottként írja le, elérhetőségük pedig attól függ, hogyan érkezett a kérés.
A VPN parancssori hookjaként futó szkript teljesen más végrehajtási környezet. Nincs webkérése, nincs klienssocketje és nincs REMOTE_ADDR-je, ezért a hookba másolt webes kód üres értékeket ad hibásak helyett. A hooknak saját környezete van, amelyet a daemon tölt fel, és külön dokumentált. Ott REMOTE_ADDR után nyúlni olyan változó után nyúlni, amelyet soha nem állítottak be.
Tartsa szem előtt ezt a különbséget, mielőtt két naplót összehasonlít. Lehet, hogy egy oldalkérést hasonlít össze egy hookkal, és az egyáltalán nem összehasonlítás. Először a végrehajtási környezetet ellenőrizze, azután a címet.
Járja végig a kérés útját, mielőtt megbízik a számban
A jelentett cím annak a kapcsolatnak a társa, amelyet a webkiszolgáló látott. Tegyen bármit a kliens és a kiszolgáló közé, és a társ megváltozik. A fordítás, a lezárás és a terheléselosztás egyaránt egy ugrással távolabb viszi a megfigyelést a felhasználótól.
Négy gyakori út négy különböző megfigyelést ad.
| Path to the listener | What can be reported |
|---|---|
| Client routed straight to the private listener, no translation | The client's tunnel address |
| Gateway translates the source before forwarding | The gateway's translated address |
| Reverse proxy terminates the client and opens its own backend connection | The proxy's backend address |
| Load balancer in front of two proxies | Whichever hop the server treats as its peer |
Írja fel az utat a cél nevével, a címcsaláddal és minden fordítási ponttal. E térkép nélkül egy helyes és egy hibás érték azonosnak látszik egy naplósorban. Két sor ábra megspórol egy délutáni vitát.
Csere csak ott történik, ahol be van állítva
Egy kiszolgáló vagy keretrendszer szándékosan helyettesítheti a kliens címét. Az Apache remote-IP modulja és az NGINX real-IP modulja is ezt teszi, és a PHP által kapott érték ettől a konfigurációtól és a szkriptkezelőnek átadott paraméterektől függ.
A REMOTE_ADDR tehát nem univerzálisan az érintetlen TCP-társ. Az a társ, ahogyan a kiszolgáló a saját szabályai alkalmazása után jelenteni döntött. Ez a különbség dönti el, hogy az érték bizonyíték-e vagy díszlet.
Kérdezze meg a kiszolgáló tulajdonosát, melyik mező mérvadó ebben a telepítésben, és hogyan őrződik meg az eredeti társ, amikor csere történik. Ha erre senki nem tud válaszolni, a napló még semmit nem bizonyít.
Ne higgyen el a továbbítási fejléceknek
A hívó maga is küldhet továbbítási fejléceket. Az első vesszővel elválasztott bejegyzést ellenőrzött felhasználói címként kezelni azt jelenti, hogy bármely csatlakozónak hiszünk, ami épp az ellenkezője annak, amire a fejléc való. A fejléc egy láncot ír le, és csak egy megbízható réteg kezeskedhet azért a láncért.
Használja a kiszolgáló vagy keretrendszer megbízható proxy támogatását a tényleges proxy-lánccal beállítva, és engedje, hogy eldobja a láncon kívüli forrásokból származó értékeket. A kézzel írt elemzés az a hely, ahol a legtöbb érdekes hiba lakik.
A proxy által jelentett cím sem változtatja meg azt a csomagforrást, amelyet egy feljebb lévő tűzfal lát. Tartsa az HTTP-metaadatokat és a hálózati szűrést külön megfigyelésként, mert különböző kérdésekre válaszolnak.
A döntésekhez az alkalmazás identitását használja
Egy felhasználó rekordjaihoz való hozzáféréshez a hitelesített principalra és az alkalmazás engedélyezési szabályaira támaszkodjon. Egy belső cím újra kiosztható, és egyetlen lefordított cím több száz egyidejű felhasználót képviselhet. E tulajdonságok egyikét sem tudja helyrehozni egy címellenőrzés.
Ha az üzemeltetésnek egy kérést VPN-munkamenethez kell kötnie, kapcsolja össze a megfigyelt címet és az időbélyeget a mérvadó munkamenet-rekordokkal a dokumentált fordítási modell szerint. Ez védhető társítást ad; egyedül egy cím nem.
Diagnosztikához csak a szükséges néhány mezőt naplózza a teljes kiszolgálótömb helyett, amely fejléceket és hitelesítési anyagot is hordozhat. A hasznos következtetés azt mondja meg, mit jelent ez az érték ebben a telepítésben, nem azt, melyik érték hasonlít leginkább egy kliensre.