Ano talaga ang sinasabi ng REMOTE_ADDR ng PHP sa likod ng VPN
Ito ay halagang ibinigay ng iyong web server, hindi isang pagtatanong sa lagusan. Sundan ang landas ng kahilingan, tingnan kung sino ang maaaring magsulat muli nito, at panatilihin ang pagkakakilanlan sa app.
May nagtatanong kung bakit lumilitaw ang isang gumagamit ng VPN sa log ng app na may address na pag-aari ng gateway, o may address na nagbago pagkatapos ng tanghalian. Nagsisimula ang sagot sa kung ano ang halagang ito: isang entry na inilagay ng web server sa kapaligiran ng kahilingan. Hindi ito pagtatanong sa lagusan, hindi pagkakakilanlan ng sertipiko, at hindi pangako na ang numero ay pag-aari ng isang tao. Ang pagbasa nito bilang alinman sa tatlong iyon ay gumagawa ng kumpiyansang sagot na mali sa iba't ibang paraan.
Ang halaga ay galing sa server, hindi sa lagusan
Tinatanggap ng PHP ang kapaligiran ng kahilingan mula sa kung ano ang nagpatakbo ng script. Inilalarawan ng sanggunian ng mga server variable ng PHP ang mga entry na ito bilang nilikha ng web server, na ang pagkakaroon ay depende sa kung paano dumating ang kahilingan.
Ang script na tumatakbo bilang hook ng command line ng VPN ay ganap na ibang konteksto ng pagpapatupad. Wala itong kahilingan sa web, walang socket ng kliyente at walang REMOTE_ADDR, kaya ang web code na kinopya sa isang hook ay nagbibigay ng walang laman na halaga sa halip na mali. Ang hook ay may sariling kapaligiran na pinupuno ng daemon, at ito ay dokumentado nang hiwalay. Ang pag-abot sa REMOTE_ADDR doon ay pag-abot sa isang variable na hindi kailanman itinakda.
Tandaan ang pagkakaibang iyon bago ihambing ang dalawang log. Baka inihahambing mo ang isang kahilingan sa pahina sa isang hook, at iyon ay hindi paghahambing. Suriin muna ang konteksto ng pagpapatupad, pagkatapos ang address.
Sundan ang landas ng kahilingan bago magtiwala sa numero
Ang iniulat na address ay ang kapares ng koneksiyon na nakita ng web server. Maglagay ng kahit ano sa pagitan ng kliyente at ng server na iyon at nagbabago ang kapares. Ang pagsasalin, pagtatapos at pagbabalanse ng karga ay bawat isa ay naglalayo sa obserbasyon nang isang hakbang mula sa gumagamit.
Apat na karaniwang landas ang gumagawa ng apat na magkaibang obserbasyon.
| 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 |
Isulat ang landas kasama ang pangalan ng destinasyon, pamilya ng address at bawat punto ng pagsasalin. Kung wala ang mapa na iyon, ang tamang halaga at maling halaga ay magkamukha sa isang linya ng log. Ang dalawang linya ng diagram ay nagtitipid ng isang hapon ng pagtatalo.
Ang pagpapalit ay nangyayari lamang kung saan ito naka-configure
Maaaring sadyang palitan ng server o framework ang address ng kliyente. Ginagawa ito ng remote-IP module ng Apache at ng real-IP module ng NGINX, at ang halagang natatanggap ng PHP ay depende sa configuration na iyon at sa mga parameter na ipinasa sa handler ng script.
Kaya ang REMOTE_ADDR ay hindi laging ang hindi nagalaw na TCP kapares. Ito ang kapares ayon sa pinili ng server na iulat pagkatapos ilapat ang sarili nitong patakaran. Ang pagkakaibang iyon ang nagpapasya kung ang halaga ay ebidensiya o dekorasyon.
Tanungin ang may-ari ng server kung aling field ang may awtoridad sa deployment na ito at paano pinapanatili ang orihinal na kapares kapag may pagpapalit. Kung walang makasagot, wala pang pinatutunayan ang log.
Huwag basahin ang mga forwarding header nang may pagtitiwala
Maaaring magpadala mismo ang tumatawag ng forwarding header. Ang ituring ang unang entry na pinaghihiwalay ng kuwit bilang beripikadong address ng gumagamit ay pagpapasya na maniwala sa sinumang kumonekta, kabaligtaran ng layunin ng header. Inilalarawan ng header ang isang kadena, at tanging isang pinagkakatiwalaang layer ang makakagarantiya sa kadenang iyon.
Gamitin ang suporta sa pinagkakatiwalaang proxy ng server o framework na may totoong proxy chain na naka-configure, at hayaang itapon nito ang mga halaga mula sa mga pinagmumulang labas ng kadenang iyon. Ang manu-manong pagsusuri ang lugar kung saan nakatira ang karamihan sa mga kawili-wiling pagkabigo.
Ang address na iniulat ng proxy ay hindi rin nagbabago sa pinagmulan ng packet na nakikita ng firewall sa itaas. Panatilihin ang HTTP metadata at pag-filter ng network bilang magkaibang obserbasyon, dahil iba ang sinasagot nila.
Gamitin ang pagkakakilanlan ng app para sa mga desisyon
Para sa pag-access sa mga rekord ng gumagamit, umasa sa na-authenticate na prinsipal at sa mga tuntunin ng awtorisasyon ng app. Ang panloob na address ay maaaring muling italaga, at ang isang naisaling address ay maaaring kumatawan sa daan-daang sabay-sabay na gumagamit. Wala sa mga katangiang ito ang maaaring ayusin ng isang pagsusuri ng address.
Kung kailangan ng operasyon na iugnay ang isang kahilingan sa isang sesyon ng VPN, ikonekta ang naobserbahang address at timestamp sa mga awtoritatibong rekord ng sesyon ayon sa modelong pagsasalin na naidokumento mo. Gumagawa iyon ng ugnayang maipagtatanggol mo; ang address lamang ay hindi.
Para sa diagnosis, i-log ang ilang field na kailangan sa halip na ang buong array ng server, na maaaring magdala ng header at materyal ng pagpapatotoo. Ang kapaki-pakinabang na konklusyon ay nagsasabi kung ano ang ibig sabihin ng halagang ito sa deployment na ito, hindi kung aling halaga ang pinakamukhang kliyente.