Белый адрес домой: статический NAT, серый WAN и проброс портов на MikroTik

Чтобы сайт с домашнего сервера открывался у всех, дому нужен адрес, на который можно прийти снаружи. По умолчанию его нет: провайдер выдаёт серый адрес из своей внутренней сети, и входящие соединения до роутера просто не доходят. Как я получил белый адрес за 100 рублей в месяц, почему на роутере он при этом всё равно серый и откуда взялись «тормоза», которых на деле не было.

Это третья часть цикла «Домашняя инфраструктура».

Три варианта от провайдера

Поддержка предложила три услуги, и звучали они похоже:

Вариант	Что это	Годится ли
«за NAT»	обычное подключение: общий внешний адрес на многих абонентов (CGNAT)	нет — снаружи до вас не дойти
«статический адрес через VPN»	туннель L2TP/PPTP до провайдера, в нём белый адрес; MTU около 1400	да, но лишний туннель, урезанный MTU, ещё одна точка отказа
«статический NAT»	персональный белый адрес, провайдер транслирует его на ваш роутер один к одному	да — его и взяли

Условия статического NAT: 100 ₽ в месяц, входящие порты не блокируются, выдача по DHCP с привязкой к MAC-адресу (привязывать надо MAC WAN-порта роутера, а не компьютера), обратную DNS-запись (PTR) делают по заявке. IPv6 нет.

На роутере серый адрес — и это нормально

После подключения первое, что смущает: на WAN-интерфейсе роутера по-прежнему адрес из 10.x.x.x, а сайты «какой у меня IP» показывают белый. Так и должно быть: белый адрес живёт на оборудовании провайдера, а до роутера пакеты доезжают уже с подменённым адресом назначения. Отсюда главное правило настройки проброса.

Проброс на MikroTik — одно правило

/ip firewall nat add chain=dstnat in-interface-list=WAN protocol=tcp dst-port=80,443 \
    action=dst-nat to-addresses=192.168.88.10 comment="web to server"

to-ports не нужен: порты те же. Фильтр трогать тоже не пришлось. Стандартный набор правил MikroTik уже содержит «отбросить из WAN всё, что не прошло через dstnat» — значит, открыты ровно те порты, которые проброшены, и ни одним больше.

Адрес сервера закреплён не в его netplan, а арендой на роутере (/ip dhcp-server lease make-static). Ошибка в netplan на машине без монитора означает поход к ней с клавиатурой, а аренда лежит рядом с правилом проброса и правится удалённо.

Проверить снаружи, а не изнутри

Изнутри дома запрос на свой белый адрес часто проходит иначе, чем у внешнего посетителя: роутер или провайдер разворачивают его, не выпуская наружу (это называется hairpin). Поэтому проверка — с машины в другой сети. Простейший способ: поднять на сервере слушатель на порту 80, сделать запрос с внешней машины на белый адрес и посмотреть, дошёл ли он.

«Дома медленнее хостинга»? Замер говорит — нет

Первое впечатление было тревожным: сайты с домашнего сервера у меня открывались заметно медленнее, чем со старого хостинга. Замерили на файле 2 МБ разными путями:

Путь	Скорость
по домашней сети напрямую	30,2 МБ/с
изнутри дома через белый адрес (hairpin)	12,4 МБ/с
домашний сервер из интернета	5,2 МБ/с в один поток, около 12 МБ/с в шесть
старый хостинг из интернета	6,6 МБ/с
мой компьютер через личный VPN	около 0,24 МБ/с

Время ответа сервера на страницу дома — 0,20–0,34 с, на хостинге — 0,21–0,32 с. Для внешнего посетителя разницы нет. Тормозил не сервер, а мой собственный путь до него: на компьютере был включён VPN, и запросы к белому адресу шли через туннель за границу и обратно. Сначала я записал причиной «медленный hairpin» — и ошибся: про включённый VPN просто забыл.

Лечение — чтобы домашние устройства вообще не ходили к своим сайтам через интернет: локальная DNS-запись на роутере отвечает на имена сайтов внутренним адресом сервера (подробно — в седьмой части), а в клиенте VPN белый адрес и домашняя подсеть добавлены в исключения.

Чек-лист

1. у провайдера — именно статический NAT или белый адрес на роутере, а не «за NAT»;
2. проверить WAN-адрес роутера: серый при статическом NAT — норма;
3. проброс по in-interface-list=WAN, только нужные порты;
4. адрес сервера — арендой на роутере;
5. проверка — с внешней машины;
6. сравнение скорости — одним путём, без VPN и прокси.