Otwierasz logi, a tam w każdej linijce ten sam adres IP. Setki wizyt i wszystkie z jednego miejsca? Albo masz jednego bardzo wiernego fana, albo coś tu nie gra.

Najpewniej to drugie. Ten adres należy do serwera pośredniczącego: Cloudflare albo wewnętrznego proxy Mikrusa, które obsługuje subdomeny wykr.es i mikrus.cloud. I to nie jest żaden błąd, tylko zwyczajne zachowanie reverse proxy. Dla Twojego serwera to proxy jest tym, kto się łączy. Prawdziwy adres odwiedzającego jedzie tylko w nagłówku X-Forwarded-For.

Czemu serwer nie bierze go stamtąd sam z siebie? Bo byłoby to naiwne. Taki nagłówek może sobie dopisać każdy i podszyć się pod dowolny adres. Dlatego ani nginx, ani Apache domyślnie mu nie wierzą. Trzeba im jawnie powiedzieć, którym adresom proxy ufać, i dopiero wtedy nagłówek zaczyna się liczyć.

Najpierw sprawdź, z jakiego adresu przychodzi proxy#

Zanim cokolwiek skonfigurujesz, musisz wiedzieć, komu ufać. Proxy Mikrusa od subdomen wykr.es i mikrus.cloud nie działa na Twoim VPS-ie, więc nie łączy się z localhost. Przychodzi z zewnątrz, zwykle po IPv6.

Najprościej podejrzeć to w logach. Wejdź na swoją subdomenę w przeglądarce i od razu zajrzyj do ostatnich wpisów:

sudo tail -n 5 /var/log/nginx/access.log
# albo dla Apache:
sudo tail -n 5 /var/log/apache2/access.log

Pierwsza kolumna każdej linii to adres, z którego przyszło połączenie. Ten, który powtarza się przy każdym Twoim odświeżeniu, to właśnie proxy. Zapisz go, przyda się za chwilę. Jeśli widzisz na zmianę dwa różne adresy (np. jeden IPv4 i jeden IPv6), zanotuj oba.

Konfiguracja w nginx (moduł realip)#

Moduł ngx_http_realip_module siedzi już w standardowym pakiecie nginx na Ubuntu i Debianie. Nic nie doinstalowujesz. Wystarczy dopisać w bloku server (albo w http, jeśli ma to dotyczyć wszystkich stron na serwerze):

set_real_ip_from ADRES_PROXY;
real_ip_header X-Forwarded-For;

W miejsce ADRES_PROXY wstawiasz adres wyczytany z logów. set_real_ip_from możesz powtarzać do woli, po jednej linii na każdy zaufany adres albo podsieć.

Siedzisz za Cloudflare? Wtedy zamiast adresu proxy Mikrusa wpisujesz całą ich pulę. Aktualna lista zawsze wisi pod cloudflare.com/ips-v4 i cloudflare.com/ips-v6:

set_real_ip_from 173.245.48.0/20;
set_real_ip_from 103.21.244.0/22;
set_real_ip_from 103.22.200.0/22;
set_real_ip_from 103.31.4.0/22;
set_real_ip_from 141.101.64.0/18;
set_real_ip_from 108.162.192.0/18;
set_real_ip_from 190.93.240.0/20;
set_real_ip_from 188.114.96.0/20;
set_real_ip_from 197.234.240.0/22;
set_real_ip_from 198.41.128.0/17;
set_real_ip_from 162.158.0.0/15;
set_real_ip_from 104.16.0.0/13;
set_real_ip_from 104.24.0.0/14;
set_real_ip_from 172.64.0.0/13;
set_real_ip_from 131.0.72.0/22;
set_real_ip_from 2400:cb00::/32;
set_real_ip_from 2606:4700::/32;
set_real_ip_from 2803:f800::/32;
set_real_ip_from 2405:b500::/32;
set_real_ip_from 2405:8100::/32;
set_real_ip_from 2a06:98c0::/29;
set_real_ip_from 2c0f:f248::/32;
real_ip_header X-Forwarded-For;

Ta lista nie jest wykuta w kamieniu. Cloudflare od czasu do czasu ją zmienia, a nic jej u Ciebie automatycznie nie odświeży. Jeśli po jakimś czasie prawdziwe adresy znowu znikną z logów, zacznij od sprawdzenia, czy lista jest aktualna.

Po zmianie configu przeładowujesz nginx:

sudo nginx -t && sudo systemctl reload nginx

Od tej chwili $remote_addr, a razem z nim logi dostępu, pokazują prawdziwy adres odwiedzającego zamiast adresu Cloudflare.

Konfiguracja w Apache (mod_remoteip)#

W Apache za tę robotę odpowiada mod_remoteip. Zwykle jest od razu po instalacji, trzeba go tylko włączyć:

sudo a2enmod remoteip

Zakładasz osobny plik konfiguracyjny:

sudo nano /etc/apache2/conf-available/remoteip.conf

RemoteIPHeader X-Forwarded-For
RemoteIPTrustedProxy ADRES_PROXY_IPV4
RemoteIPTrustedProxy ADRES_PROXY_IPV6

Tu też podstawiasz adresy z logów. Jeśli proxy przychodzi tylko po jednym protokole, zostaw jedną linię. Za Cloudflare wpisujesz w RemoteIPTrustedProxy ich pule, tak samo jak w nginx.

Zwróć uwagę, że w przykładzie są adresy i w wersji IPv4, i IPv6. To nie przypadek. Pominiesz IPv6, a ruch, który przyjdzie do serwera po IPv6 (a na Mikrusie kontener ma taki adres bezpośrednio), nie zostanie uznany za zaufany. %a w logach dalej będzie wtedy pokazywać adres proxy.

Włączasz konfigurację i przeładowujesz Apache:

sudo a2enconf remoteip
sudo systemctl reload apache2

Jeśli Twój LogFormat używa %a (adres klienta), od teraz zacznie pokazywać prawdziwy adres. Samego LogFormat nie ruszasz. mod_remoteip podmienia to, co %a uważa za “adres klienta”, na poziomie całego serwera.

Najczęstsze błędy#

Zaufany tylko adres IPv4 proxy, a ruch przychodzi po IPv6. Na Mikrusie to szczególnie częste, bo kontener ma prawdziwy adres IPv6 obok NAT-owanego IPv4. Zawsze dodawaj obie wersje.

Wpisanie 127.0.0.1 “bo proxy jest Mikrusa”. Proxy od subdomen stoi na osobnym serwerze, nie na Twoim VPS-ie. Zaufanie do localhost niczego tu nie zmieni. Sprawdź w logach, skąd naprawdę przychodzi ruch.

Zaufanie zbyt szerokiej puli, np. 0.0.0.0/0. Wtedy całe to zabezpieczenie idzie do kosza. Każdy odwiedzający może podesłać własny X-Forwarded-For i udawać, kogo tylko zechce. Ufaj wyłącznie rzeczywistym adresom swojego proxy.

Zmiana configu bez przeładowania. nginx -t i apache2ctl configtest sprawdzają tylko składnię. Żeby zmiany weszły w życie, potrzebny jest jeszcze reload albo restart.

Nieaktualna lista adresów Cloudflare. Jeśli po kilku miesiącach realip nagle przestaje działać, to pierwszy podejrzany.

I tyle. Logi i aplikacja widzą teraz prawdziwych odwiedzających, a nie w kółko ten sam serwer pośredniczący.