Co tak naprawdę mówi REMOTE_ADDR w PHP za VPN-em
To wartość podana przez serwer WWW, a nie zajrzenie do tunelu. Prześledź drogę żądania, sprawdź, kto może je przepisać, i trzymaj tożsamość w aplikacji.
Ktoś pyta, dlaczego użytkownik VPN pojawia się w logu aplikacji z adresem należącym do bramy, albo z adresem, który zmienił się po obiedzie. Odpowiedź zaczyna się od tego, czym ta wartość jest: wpisem, który serwer WWW umieścił w środowisku żądania. To nie jest zapytanie do tunelu, nie tożsamość certyfikatu i nie obietnica, że numer należy do jednej osoby. Czytanie jej jako którejkolwiek z tych trzech rzeczy daje pewne siebie odpowiedzi, które są błędne na różne sposoby.
Wartość pochodzi z serwera, nie z tunelu
PHP otrzymuje środowisko żądania od tego, co wykonało skrypt. Dokumentacja zmiennych serwera PHP opisuje te wpisy jako tworzone przez serwer WWW, a ich dostępność zależy od sposobu, w jaki żądanie dotarło.
Skrypt uruchamiany jako hook wiersza poleceń VPN to zupełnie inny kontekst wykonania. Nie ma żądania sieciowego, gniazda klienta ani REMOTE_ADDR, dlatego skopiowany kod webowy w hooku daje puste wartości zamiast błędnych. Hook ma własne środowisko, wypełniane przez demona, i jest opisany osobno. Sięganie tam po REMOTE_ADDR to sięganie po zmienną, której nigdy nie ustawiono.
Miej tę różnicę w głowie, zanim porównasz dwa logi. Być może porównujesz żądanie strony z hookiem, a to nie jest żadne porównanie. Najpierw sprawdź kontekst wykonania, a potem adres.
Przejdź drogę żądania, zanim zaufasz numerowi
Zgłaszany adres to peer tego połączenia, które widział serwer WWW. Wstaw cokolwiek między klienta a ten serwer, a peer się zmieni. Tłumaczenie, terminacja i równoważenie obciążenia przesuwają każde obserwację o jeden skok dalej od użytkownika.
Cztery typowe drogi dają cztery różne obserwacje.
| 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 |
Zapisz drogę z nazwą celu, rodziną adresów i każdym punktem tłumaczenia. Bez tej mapy poprawna i błędna wartość wyglądają identycznie w wierszu logu. Dwie linie diagramu oszczędzają popołudnie dyskusji.
Podmiana następuje tylko tam, gdzie jest skonfigurowana
Serwer lub framework może świadomie podmienić adres klienta. Moduł remote-IP Apache'a i moduł real-IP NGINX-a robią właśnie to, a wartość otrzymywana przez PHP zależy od tej konfiguracji oraz parametrów przekazanych do handlera skryptu.
REMOTE_ADDR nie jest więc uniwersalnie nietkniętym peerem TCP. To peer taki, jak serwer postanowił go zgłosić po zastosowaniu własnej polityki. Ta różnica decyduje, czy wartość jest dowodem, czy ozdobą.
Zapytaj właściciela serwera, które pole jest autorytatywne w tym wdrożeniu i jak zachowywany jest pierwotny peer, gdy następuje podmiana. Jeśli nikt nie potrafi odpowiedzieć, log jeszcze niczego nie dowodzi.
Nie czytaj nagłówków przekazywania na wiarę
Wywołujący może sam wysłać nagłówki przekazywania. Potraktowanie pierwszego wpisu oddzielonego przecinkami jako zweryfikowanego adresu użytkownika to decyzja, by wierzyć każdemu, kto się połączy, czyli odwrotność celu tego nagłówka. Nagłówek opisuje łańcuch i tylko zaufana warstwa może za ten łańcuch ręczyć.
Użyj obsługi zaufanych proxy serwera lub frameworka z skonfigurowanym rzeczywistym łańcuchem proxy i pozwól jej odrzucać wartości ze źródeł spoza tego łańcucha. Parsowanie pisane ręcznie to miejsce, w którym mieszka większość interesujących awarii.
Adres zgłoszony przez proxy nie zmienia też źródła pakietów, które widzi zapora powyżej. Trzymaj metadane HTTP i filtrowanie sieciowe jako osobne obserwacje, bo odpowiadają na różne pytania.
Do decyzji używaj tożsamości aplikacji
Przy dostępie do rekordów użytkownika opieraj się na uwierzytelnionym podmiocie i regułach autoryzacji aplikacji. Wewnętrzny adres może zostać przydzielony ponownie, a jeden przetłumaczony adres może reprezentować setki równoczesnych użytkowników. Żadnej z tych właściwości nie naprawi sprawdzanie adresu.
Jeśli utrzymanie musi powiązać żądanie z sesją VPN, połącz zaobserwowany adres i znacznik czasu z autorytatywnymi zapisami sesji według udokumentowanego modelu tłumaczenia. To daje powiązanie, którego można bronić; sam adres nie.
Do diagnostyki loguj te kilka potrzebnych pól zamiast całej tablicy serwera, która może zawierać nagłówki i materiał uwierzytelniający. Użyteczny wniosek mówi, co ta wartość znaczy w tym wdrożeniu, a nie która wartość najbardziej przypomina klienta.