Почему Apache регистрирует внутренний IP-адрес при использовании внешнего домена?
у меня работает Raspberry Pi, который мы используем в офисе для небольших тестовых проектов, которые нам не нужны на нашем основном сервере разработки. На нем работает апач. DNS обрабатывается через Cloudflare, но в режиме «Только DNS». В настоящее время, пока я тестирую, ограничений по IP нет. Запись A для mysite.domain.tldуказывает на мой статический IP-адрес 123.123.123.123, и между Интернетом и Pi находится только стандартный оптоволоконный маршрутизатор/модем для бизнеса.
Когда я захожу на mysite.domain.tld, например, с моего телефона без Wi-Fi, появляется IP-адрес сотового оператора. Когда я wgetс удаленного сервера, его IP-адрес отображается в журналах. Все работает так, как ожидалось.
Однако, когда я перехожу к mysite.domain.tldиз той же сети, в которой находится Pi, apache регистрирует IP-адрес шлюза маршрутизатора 192.168.1.1. Я ожидаю увидеть свой общедоступный IP-адрес, потому что мое подключение к доменному имени разрешается через Cloudflare в общедоступный IP-адрес. Но вместо этого я вижу в журналах IP-адрес локальной сети.
Ничего не установлено в/etc/hosts(Я на macOS)и на маршрутизаторе, только порт-переадресация для соединений с порта 443 маршрутизатор на Pi на том же порту -ничего относительно доменное имя является ссылкой в любом месте. Когда я пингую mysite.domain.tld, он дает мне IP-адрес Cloudflare , чего я и ожидал.
Похоже, что где-то в цепочке тот факт, что мой IP-адрес и общедоступный IP-адрес Pi совпадают, поэтому он переопределяет IP-адрес с IP-адресом внутреннего шлюза. Что здесь происходит на самом деле? Я не возражаю как таковому, я просто хочу убедиться, что могу полагаться на тот факт, что 192.168.*IP-адресам можно доверять при настройке ограничения IP-адресов на брандмауэре.
Примечание:CF-Connecting-IP и подобные заголовки здесь не отправляются Cloudflare, я предполагаю, что это происходит только тогда, когда не в режиме «Только DNS». И это кажется только тогда, когда я использую то же сетевое соединение, что и Pi.
Ваш маршрутизатор работает под управлением Linux, и такое поведение легко реализовать в любом стандартном дистрибутиве Linux. Я могу предположить, какие правила должны присутствовать в брандмауэре вашего маршрутизатора, чтобы он работал так. Но имейте в виду, что это всего лишь предположение, мы не знаем, как именно правила выглядят на самом деле.
Когда вы перенаправляли порт на свой веб-сервер, он добавлял определенное правило DNAT, которое, вероятно, выглядит следующим образом:
iptables -t nat -A PREROUTING -p tcp -d <your-external-address> --dport 443 -j DNAT --to-destination <raspberry-pi-address>
На словах это означает:«прежде чем решить, предназначен ли этот пакет для устройства или должен быть перенаправлен, проверьте, является ли адрес назначения пакета вашим внешним адресом, а порт назначения — 443. Если он совпадает, измените адрес назначения на адрес локальной сети Raspberry Pi». Обратите внимание, это правило не фильтрует по интерфейсу.
Также у него определенно есть правило типа SNAT-(для предоставления доступа в интернет для локальной сети), возможно, это выглядит так:
iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -j MASQUERADE
Другими словами, после того, как маршрутизатор решает, куда пакет должен идти, перед отправкой пакета он изменяет свой исходный адрес на любой адрес исходящего интерфейса (, если пакет был отправлен из локальной сети ). Опять же, интерфейс ничего не фильтрует.
Теперь рассмотрим ваше HTTPS-соединение. Вы указываете имя хоста в браузере, верно? Вы настраиваете его так, чтобы он разрешался во внешний адрес вашего маршрутизатора, который становится адресом назначения. Ваш исходный адрес находится внутри локальной сети. Итак, кажется, что оба эти правила применимы к пакетам вашего соединения.
Обрабатывая их, маршрутизатор сначала сталкивается с правилом DNAT, проверяет адрес и порт назначения и решает изменить адрес назначения на адрес raspberry pi. Затем он обнаруживает, что интерфейс, через который должен выйти пакет, — это LAN. Затем он проверяет частично транслированный пакет на соответствие второму правилу и выясняет, что исходный адрес находится в локальной сети. Таким образом, он заменяет исходный адрес пакета адресом LAN-интерфейса 192.168.1.1. Это то, что видит ваш Raspberry Pi.
Операция NAT зависит от состояния, т.е.он также поддерживает запись в таблице, в которой говорится, что было заменено чем и как обнаруживать последующие пересылаемые и ответные пакеты, поэтому он все их правильно переводит. Да, оказывается, Linux может выполнять DNAT и SNAT одновременно в одном потоке.
Можно ли доверять такому поведению? Я не знаю. Если прошивка маршрутизатора была с открытым исходным кодом, у нас была возможность проверить. Без источника мы не можем быть уверены. Это всегда так, когда исходный код закрыт, поэтому следует избегать продуктов с закрытым исходным кодом, если вы беспокоитесь о безопасности.