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