Що насправді означає REMOTE_ADDR у PHP за VPN
Це значення, яке надав ваш вебсервер, а не запит усередину тунелю. Пройдіть шлях запиту, перевірте, хто може його переписати, і тримайте ідентичність у застосунку.
Хтось питає, чому користувач VPN з'являється в журналі застосунку з адресою, що належить шлюзу, або з адресою, яка змінилася після обіду. Відповідь починається з того, що це за значення: запис, який вебсервер помістив в оточення запиту. Це не запит усередину тунелю, не ідентичність сертифіката й не обіцянка, що номер належить одній людині. Якщо читати його як будь-що з цих трьох, виходять упевнені відповіді, які помилкові по-різному.
Значення надходить від сервера, а не з тунелю
PHP отримує оточення запиту від того, що виконало скрипт. Довідник серверних змінних PHP описує ці записи як створені вебсервером, а їхня доступність залежить від того, як надійшов запит.
Скрипт, запущений як hook командного рядка VPN, — цілком інший контекст виконання. У нього немає вебзапиту, немає клієнтського сокета й немає REMOTE_ADDR, тому скопійований вебкод у hook дає порожні значення, а не хибні. У hook є власне оточення, яке заповнює демон, і воно задокументоване окремо. Тягнутися там до REMOTE_ADDR — це тягнутися до змінної, яку ніколи не задавали.
Тримайте цю різницю в голові, перш ніж порівнювати два журнали. Можливо, ви порівнюєте запит сторінки з hook, а це зовсім не порівняння. Спершу перевірте контекст виконання, а потім адресу.
Пройдіть шлях запиту, перш ніж довіряти номеру
Повідомлена адреса — це peer того з'єднання, яке бачив вебсервер. Вставте будь-що між клієнтом і цим сервером, і peer зміниться. Трансляція, термінація та балансування кожна зсувають спостереження на один крок далі від користувача.
Чотири звичайні шляхи дають чотири різні спостереження.
| 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 |
Запишіть шлях з іменем призначення, родиною адрес і кожною точкою трансляції. Без цієї карти правильне й хибне значення виглядають у рядку журналу однаково. Два рядки схеми економлять півдня суперечок.
Заміна відбувається лише там, де вона налаштована
Сервер або фреймворк може навмисно підмінити адресу клієнта. Модуль remote-IP в Apache і модуль real-IP в NGINX роблять саме це, а значення, яке отримує PHP, залежить від цієї конфігурації та параметрів, переданих обробнику скрипта.
Отже, REMOTE_ADDR — не завжди недоторканий TCP-peer. Це peer у тому вигляді, у якому сервер вирішив його повідомити, застосувавши власну політику. Ця різниця вирішує, чи є значення доказом, чи прикрасою.
Запитайте власника сервера, яке поле є авторитетним у цьому розгортанні та як зберігається початковий peer, коли відбувається підміна. Якщо ніхто не може відповісти, журнал поки нічого не доводить.
Не читайте заголовки пересилання на віру
Викликач може сам надіслати заголовки пересилання. Вважати перший запис через кому перевіреною адресою користувача — це рішення вірити кожному, хто підключився, тобто протилежність тому, для чого потрібен заголовок. Заголовок описує ланцюжок, і лише довірений шар може поручитися за цей ланцюжок.
Використовуйте підтримку довірених проксі сервера або фреймворку з налаштованим реальним ланцюжком проксі та дайте їй відкидати значення з джерел поза цим ланцюжком. Розбір, написаний вручну, — місце, де живе більшість цікавих відмов.
Адреса, повідомлена проксі, також не змінює джерело пакетів, яке бачить вищий міжмережевий екран. Тримайте метадані HTTP і мережеву фільтрацію як окремі спостереження, бо вони відповідають на різні питання.
Для рішень використовуйте ідентичність застосунку
Для доступу до записів користувача покладайтеся на автентифікований суб'єкт і правила авторизації застосунку. Внутрішню адресу можна перепризначити, а одна трансльована адреса може представляти сотні одночасних користувачів. Жодну з цих властивостей перевірка адреси не виправить.
Якщо експлуатації потрібно пов'язати запит із сесією VPN, з'єднайте спостережувану адресу та позначку часу з авторитетними записами сесій за задокументованою моделлю трансляції. Це дає зв'язок, який можна захистити; сама адреса — ні.
Для діагностики записуйте ті кілька потрібних полів замість усього масиву сервера, який може нести заголовки й матеріал автентифікації. Корисний висновок каже, що це значення означає в цьому розгортанні, а не яке значення найбільше схоже на клієнта.