Проброс портов и настройка роутера для внешнего доступа

Содержание

Содержание

Домашний роутер обычно не дает возможности добраться из внешнего Интернета до компьютеров во внутренней сети. Это правильно — хакерские атаки рассчитаны на известные уязвимости компьютера, так что роутер является дополнительным препятствием. Однако бывают случаи, когда доступ к роутеру и его локальным ресурсам из «внешнего мира» становится необходим. О том, в каких случаях бывает нужен доступ извне, и как его безопасно настроить — эта статья.

Зачем открывать доступ извне?

Доступ «снаружи» нужен не только в экзотических случаях вроде открытия игрового сервера или запуска сайта на домашнем компьютере. Гораздо чаще приходится «открывать порт» для многопользовательской игры, а это — как раз предоставление внешнему пользователю (серверу игры) доступа к внутренней сети (порт компьютера). Если необходимо удаленно подключиться и настроить компьютер или роутер, скачать файл-другой из домашней сети, находясь в командировке, или посмотреть видео с подключенных к домашней сети IP-камер — нужно настроить доступ.

Цвета и формы IP-адресов

Прежде чем разбираться, как открыть доступ к своим ресурсам, следует понять, как вообще происходит соединение в сети Интернет. В качестве простой аналогии можно сравнить IP-адрес с почтовым адресом. Вы можете послать письмо на определенный адрес, задать в нем какой-то вопрос и вам придет ответ на обратный адрес. Так работает браузер, так вы посещаете те или иные сайты.

Но люди общаются словами, а компьютеры привыкли к цифрам. Поэтому любой запрос к сайту сначала обрабатывается DNS-сервером, который выдает настоящий IP-адрес.

Допустим теперь, что кто-то хочет написать письмо вам. Причем не в ответ, а самостоятельно. Не проблема, если у вас статический белый адрес — при подключении сегодня, завтра, через месяц и год он не поменяется. Кто угодно, откуда угодно, зная этот адрес, может написать вам письмо и получите его именно вы. Это как почтовый адрес родового поместья или фамильного дома, откуда вы не уедете. Получить такой адрес у провайдера можно только за отдельную и регулярную плату. Но и с удаленным доступом проблем меньше — достаточно запомнить выданный IP.

Обычно провайдер выдает белый динамический адрес — какой-нибудь из незанятых. Это похоже на ежедневный заезд в гостиницу, когда номер вам выдается случайно. Здесь с письмом будут проблемы: получить его можете вы или другой постоялец — гарантий нет. В таком случае выручит DDNS — динамический DNS.

Самый печальный, но весьма распространенный в последнее время вариант — серый динамический адрес: вы живете в общежитии и делите один-единственный почтовый адрес с еще сотней (а то и тысячей) жильцов. Сами вы письма писать еще можете, и до адресата они дойдут. А вот письмо, написанное на ваш почтовый адрес, попадет коменданту общежития (провайдеру), и, скорее всего, не пойдет дальше мусорной корзины.

Сам по себе «серый» адрес проблемой не является — в конце концов, у всех подключенных к вашему роутеру устройств адрес именно что «серый» — и это не мешает им пользоваться Интернетом. Проблема в том, что когда вам нужно чуть больше, чем просто доступ к Интернету, то настройки своего роутера вы поменять можете, а вот настройки роутера провайдера — нет. В случае с серым динамическим адресом спасет только VPN.

Кто я, где я, какого я цвета?

С терминологией разобрались, осталось понять, какой именно адрес у вас. У большинства провайдеров фиксированный адрес стоит денег, так что если у вас не подключена услуга «статический IP-адрес», то он наверняка динамический. А вот белый он или серый гусь — это нужно проверить. Для начала надо узнать внешний IP-адрес роутера в его веб-интерфейсе и сравнить с тем адресом, под которым вас «видят» в Интернете.

В админ-панели роутера свой IP можно найти на вкладках «Информация о системе», «Статистика», «Карта сети», «Состояние» и т. п. Где-то там нужно искать WAN IP.

Если адрес начинается с «10.», или с «192.168.», то он определенно «серый» — большинство способов открытия доступа работать не будет и остается только VPN.

Если же адрес выглядит по-другому, надо посмотреть на него «снаружи» с помощью одного из сервисов, показывающих ваш IP-адрес, например, http://myip.ru/.

Если адрес, показанный на сайте, совпадает с тем, что вы увидели в веб-интерфейсе, то у вас честный «белый» адрес и доступ из «большого мира» не вызовет особых затруднений — остается только настроить «пробросы» на роутере и подключить DDNS.

Что такое порты и зачем их бросать?

Порт — это пронумерованное виртуальное «устройство», предназначенное для передачи данных по сети. Каждая сетевая программа использует для установления связи отдельный порт или группу портов. К примеру, браузеры используют TCP-порт 80 для незашифрованного трафика (http) и 443 для зашифрованного (https).

Проброс порта — это специальное правило в роутере, которое разрешает все обращения извне к определенному порту и передает эти обращения на конкретное устройство во внутренней сети.

Необходимость «проброса» портов обычно возникает при желании сыграть по сети в какую-нибудь игру с компьютера, подключенного к роутеру. Впрочем, это не единственная причина — «проброс» потребуется при любой необходимости получить «извне» доступ к какому-нибудь конкретному устройству в вашей локальной сети.

Разрешать к компьютеру вообще все подключения, то есть пробрасывать на него весь диапазон портов — плохая идея, это небезопасно. Поэтому роутеры просто игнорируют обращения к любым портам «извне». А «пробросы» — специальные исключения, маршруты трафика с конкретных портов на конкретные порты определенных устройств.

Игровые порты: что, куда бросаем?

Какой порт открыть — зависит от конкретного программного обеспечения. Некоторые программы требуют проброса нескольких портов, другим — достаточно одного.

У разных игр требования тоже отличаются — в одни можно играть даже с «серого» адреса, другие без проброса портов потеряют часть своих возможностей (например, вы не будете слышать голоса союзников в кооперативной игре), третьи вообще откажутся работать.

Например, чтобы сыграть по сети в «Destiny 2», нужно пробросить UDP-порт 3074 до вашей «плойки», или UDP-порт 1200 на Xbox. А вот до ПК потребуется пробросить уже два UDP-порта: 3074 и 3097.

В следующей таблице приведены некоторые игры и используемые ими порты на ПК:

Шпаргалка по пробросу IP во внутреннюю сеть без моста и iptables в 4 команды

В статье будет рассмотрена маршрутизация внешнего IP-адреса внутрь локальной без пробрасывания ethernet-шлюза и переписывания адресов в iptables. В итоге на сетевой карте внутреннего сервера будет один правильный внешний IP-адрес, внутренние IP-адреса будут отсутствовать.

Практика применения: например маршрутизация IP-адресов с сервера на виртуальные машины, без необходимости подключать их к ethernet-сети физического сервера.
При этом на сетевой интерфейс может быть назначена как сеть адресов, так и разрозненные адреса, у которых этот сервер указан просто как следующий узел маршрутизации (так например Hetzner раздает свои отказоустойчивые IP-адреса).

Исходное состояние

Сервер S1 — сервер во внутренней сети или виртуальный сервер, для которого нужно пробросить внешний IP-адрес, у него есть один сетевой интерфейс — eth0, включенный в brLAN.

iptables на обоих серверах выключен

Краткая шпаргалка по командам

Сервер S1 (внутренний)

На этом всё: для S1 внутренних IP-адресов назначать не нужно — пакеты сразу отправляются с публичного адреса.

Настройка клиента через конфиги

Как настроить через конфиги сервер пока не нашел, но в целом это меньшая проблема — один шлюз контролировать просто и настройка элементарная — просто для каждого адреса (сети адресов) вызывать команду направления трафика во внутреннюю сеть — это можно хоть просто скриптом сделать и включить в автозагрузку.

Преимущества перед iptables с пробросом на внутренний IP

Как избавиться от 192.168.0.1

P.S. в принципе адрес 192.168.0.1 тоже можно исключить и указывать вместо него любой IP-адрес сервера-шлюза, например его публичный IP, тогда трассировка пути будет смотреться красиво. При установках по умолчанию всё будет работать, но могут возникать ньюансы.

Например возможность отвечать по своим IP-адресам с любого интерфейса может иногда мешать и должна быть выключена. Или если сменится публичный IP-адрес шлюза (например виртуалка переехала на другой физический сервер) — нужно будет менять настройки внутреннего сервера. При использовании для шлюза отдельного, общего для всех подобных шлюзов адреса такой проблемы не возникает.

Читают сейчас

Редакторский дайджест

Присылаем лучшие статьи раз в месяц

Скоро на этот адрес придет письмо. Подтвердите подписку, если всё в силе.

Похожие публикации

Alma, но не Mater: встречайте AlmaLinux, «наследника» CentOS 8

Быстрый роутинг и NAT в Linux

Resolve IP адресов в Linux: понятное и детальное описание

Вакансии

AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Минуточку внимания

Комментарии 39

Новизна как раз в том что маршрутизируется левый одиночный IP-адрес (не сеть), не имеющий ничего общего с адресом сервера-шлюза. И на внутреннем сервере никак не получится настроить маршрутизацию обычным образом через подсеть и шлюз пол умолчанию с IP из той же сети.

Поясняю на примере из практики по которому статья и написана:
Есть сервер с публичным адресом 1.1.1.1
Кроме этого на сервере добавлен отказоустойчивый IP 1.2.3.4, который может перекидываться между серверами через API дата-центра. Это одиночный IP-адрес (не сеть адресов), у него нет макси и шлюза по умолчанию со стороны дата-центра.
Нужно назначить этот адрес на виртуальную машину внутри сервера таким образом, чтобы можно было быстро и удобно поднять копию этой виртуальной машины на другом физическом сервере.
При этом на сетевом интерфейсе виртуальной машины должен быть IP-адрес 1.2.3.4, т.к. внутри установлен софт который привязывается к IP-адресу и проверяет его как запросами во внешнюю сеть, так и по наличию адреса на интерфейсе с которого эти запросы в сеть уходят.

Попробуйте поискать инструкции про проброс внешнего IP-адреса к серверу из локальной сети, я много раз искал такие инструкции и всегда находил только тот или иной вариант настройки перенаправлений через iptables. При этом трафик ходит, но внешний IP-адрес на внутреннем сервере отсутствует (это для меня было основным в данном случае) + как оказалось вариант с маршрутизацией еще и настраивается проще.

Простите, для интереса, а какой публичный адрес вы назначили самому серверу S0?

(Если бы ему был назначен 1.2.3.4, ваша команда маршрутизации на нём ip route 1.2.3.4 255.255.255.255 куда-угодно была бы совершенно бесполезна, т.к. в его таблице local, которая обрабатывается всегда первой, уже была бы запись local 1.2.3.4 dev eth0 proto kernel scope host src 1.2.3.4)

Я тоже так предполагаю. Но это нужно было написать, а то вдруг автор изобрёл неведомое мне страшное колдунство в линуксе, про которое я до сих пор не знал.

Если так, то вообще непонятно, зачем эта статья. Это базовая маршрутизация IP, с этого начинается изучение собственно процесса маршрутизации. И непонятно, зачем тут вообще упомянут iptables и зачем маршрутизатор сравнивают с пакетным фильтром.

Поправил входные данные, добавил что есть внешний адрес, который не используется в настройках.

Она возможно и базовая и те кто изучают маршрутизацию в вузах/курсах возможно это и изучают еще в начале. Однако по вопросу проброса IP-адреса я находил исключительно варианты с подменой адресов в iptables, поэтому с ним и сравниваю.

Посмотрите например yandex google
а статья как раз и призвана показать более правильный способ.

P.S. заголовок тоже поправил, чтобы по пробросу статья легко находилась.

«Проброс» — это вообще жаргон, который обозначает трансляцию (адреса и/или порта). То есть, совершенно нормально и правильно, что вы по запросу «как сделать трансляцию адреса» находили статьи про трансляцию адреса. Совет: завязывайте с жаргоном, он скрывает от вас смысл ваших действий. Называйте вещи своими именами.

Маршрутизация — это не «проброс». И запрос поисковый, соответственно, должен быть другой. Это настолько основы, что даже затрудняюсь подсказать, как это искать — это тупо описано в каждом учебнике по tcp/ip. Вкратце — для машршутизации нужно включить форвардинг пакетов и прописать необходимые маршруты.

Как в вашей статье образовался iptables я понимаю — вы всё изучали по статьям типа «хау ту», вместо последовательного чтения учебников и стандартов (RFC), что плохо. А ещё хуже то, что образовавшейся кашей в голове вы делитесь с окружающими. Не надо так.

«Проброс» — это вообще жаргон, который обозначает трансляцию (адреса и/или порта). То есть, совершенно нормально и правильно, что вы по запросу «как сделать трансляцию адреса» находили статьи про трансляцию адреса. Совет: завязывайте с жаргоном, он скрывает от вас смысл ваших действий. Называйте вещи своими именами.

К сожалению жаргон нигде не закреплен и каждый может понимать его немного по-своему, в частности я не нашел определения слова «проброс» в контекста нашего общения.
Впрочем по марштуризации внешнего IP во внутренюю сеть тоже.

Изучение RFC хорошо для понимания основ работы протокола, но к сожалению не дает представления об инструментах и практике применения.

Про учебники: к сожалению я не видел учебников, объясняющих подобные вещи. Подскажите мне — я с удовольствием почитаю.

А ещё хуже то, что образовавшейся кашей в голове вы делитесь с окружающими. Не надо так.

Подобные азы маршрутизации описаны в RFC 1180 (это туториал-учебник). Можно почитать перевод.

А по поводу каши в голове… Просто представьте себе свою статью без упоминания iptables, и она сократится до пятнадцати строк, вроде этого. А это непосредственно в RFC-учебнике конечно не написано, но следует напрямую. Это явно недостойно отдельной статьи.

Я прочитал этот RFC и из него я бы понял теорию «я хочу отправить IP 1.2.3.4 в сеть brLAN, а с S1 отправить трафик через S0 во внешний мир», т.е. это фоновые знания о том как работает маршрутизация в принципе, к сожалению этот RFC не описывает и даже не намекает на то как достигнуть желаемого результата на практике.
Статья же призвана решить конкретную практическую задачу, т.е. это просто разные вещи.

К тому же примеры именно про то что каждому ethernet-фрагменту соответствует своя подсеть IP-адресов — точно так же как во всех руководствах, учебниках и статьях которые я видел по IPv4 (в отличие от IPv6 где шлюз в другой подсети это норма). Поскольку везде приведены именно такие примеры, то иное поведение (шлюз с IP из другой сети) совершенно неочевидно.

Сравнение с iptables включено в статью специально — как раз чтобы показать что это более правильная альтернатива популярному костылю.

этот RFC не описывает и даже не намекает на то как достигнуть желаемого результата на практике

Всё верно — внутренний IP на S1 не требуется. При отправке пакетов в качестве адреса источника указывается публичный IP 1.2.3.4.
192.168.0.1 это просто удобный маркер, чтобы внутри ethernet-сети brLAN найти MAC-адрес интерфейса на который отправлять пакеты, предназначенные публичной сети. В конце статьи описано как избавиться и от него тоже.

Работает это так:
При отправке пакета S1 смотрит свою таблицу маршрутизации и видит там указание:
— Весь внешний трафик отправлять через 192.168.0.1, смотрит как достучаться до 192.168.0.1
— пакеты на 192.168.0.1 слать через интерфейс eth0 (в сеть brLAN)
— S1 отправляет ARP-запрос вида: «У кого в этой сети IP 192.168.0.1» и получает ответ с интерфейса сервера S0
— S1 отправляет пакет с адресом источника 1.2.3.4 и адресом назначения на интерфейс S0 по его MAC-адресу, а S0 уже продвигает его дальше

При обратном процессе:
— S0 получает пакет для 1.2.3.4 и смотрит свою таблицу маршрутизации
— видит правило — пакеты для 1.2.3.4 отправлять в сеть brLAN
— S0 отправляет ARP-запрос «У кого в этой сети адрес 1.2.3.4?» и получает ответ с интерфейса S1
— отправляет трафик для 1.2.3.4 на интерфейс S1 по его MAC-адресу.

Если не назначать дополнительных внутренних адресов — да.
С другой стороны никто не мешает это сделать при необходимости.

В моем случае S1 это виртуальный сервер и если S0 сдохнет то к S1 я всё равно не попаду пока не подниму его на другом физическом сервере — а там он снова по публичному адресу будет доступен.

Через маршрутизатор. Перечитайте, на S1 добавляется прямой маршрут до системы 192.168.0.1, и потом весь трафик направляется через неё.

По сути, назначение адреса, например, 192.168.0.5/24 на интерфейс eth0 производит в системе следующее:

— Система запоминает адрес 192.168.0.5 как «свой», и будет передавать пакеты, назначенные этому адресу, соответствующим процессам;
— Добавляется маршрут local 192.168.0.5, чтобы с самой системы пакеты на этот адрес заворачивались на lo. То есть, наружу не уходили. Более того, маршрут добавляется в таблицу local (можете посмотреть его полностью командой ip route show table local), которая всегда обрабатывается первой (в правиле RPDB 0, можете проверить комадной ip rule show — правило 0 гласит lookup table local, правило 65534 — lookup table main, в которую маршруты попадают по умолчанию, 65535 — default, которая пуста).
— Добавляется маршрут 192.168.0.0/24 dev eth0, т.е. «все пакеты этой сети направлять непосредственно через интерфейс eth0». Он добавляется в таблицу main.

Маска подсети влияет только на вид последнего маршрута. Можно достичь абсолютно того же эффекта, если написать ip addr add 192.168.0.5/32 dev eth0; ip route add 192.168.0.0/24 dev eth0. Сравните эти два правила с тем, что написано в статье — разница только в том, что вместо маршрута для всей сети добавляется маршрут до одного адреса. А потом вся сеть маршрутизируется через этот адрес.

Если кто-то арендует сервере в Hetzner, то уже знает, что именно так у них всё и работает. И если вы запросите дополнительные адреса и назначаете их виртуалкам, вам придётся делать маршрутизацию абсолютно так, как написано в этой статье. То же самое, к слову, написано и в вики Хетцнера.

Если кто-то арендует сервере в Hetzner, то уже знает, что именно так у них всё и работает. И если вы запросите дополнительные адреса и назначаете их виртуалкам, вам придётся делать маршрутизацию абсолютно так, как написано в этой статье. То же самое, к слову, написано и в вики Хетцнера.

Да, действительно — нашел у них даже пример конфигов Centos Debian
Допишу в статью настройку для сервера через конфиги.

А чем плохо?
Ну записал бы я себе это в локальный блокнот кому бы от этого лучше стало, кроме меня?

А так есть хороший шанс, что кто-то вместо костыля с iptables настроит себе правильную маршрутизацию.
Что же делать если такой простой вопрос как маршрутизация внешнего IP на сервер во внутренней сети часто решается таким грубым и популярным костылем как iptables и подмена адресов через него.

Популярным среди кого?

Почему бы ещё не писать каждые полгода таториал по установке очередной версии убунту — тоже наверняка кто-то в поиске найдёт и прочитает, и оно будет востребовано. Однако, если постоянно идти на поводу востребованности большинством, то на выходе будет ширпотреб. Я не говорю, что это плохая стратегия, но применительно к этому ресурсу она убьёт его в текущем качестве.

Популярным среди тех кто пишет инструкции — подобная задача у меня возникала в разных вариантах в разные годы и ни разу я не нашел никакой инструкции о её решении через маршрутизацию. Т.е. на теоретическом уровне я знал что это возможно, но как сделать — было совершенно непонятно. В предыдущих задачах вопрос «как» был второстепенным — нужно было чтобы трафик доходил до места назначения и я тоже делал по тем инструкциям которые находил, тоже костылем через iptables, т.к. глубоко изучать тему маршрутизации для того чтобы условно получить http-запрос на виртуалке смысла не вижу. Если глубоко всесторонне изучать каждый вопрос который приходится решать — до решения можно так и не дойти, поэтому приходилось пользоваться инструкциями которые просто работали.

Потом моя задача усложнилась и стало нужно делать это:
1. Просто — для автоматизации
2. Надежно и понятно — без танцев вокруг iptables с разными вариантами того откуда пакет пришел
3. Сохранять IP для исходящего трафика, а не только принимать входящий

И пришло время изучить тему более подробно, применив тот объем фоновых знаний который уже накопился в процессе других экспериментов с маршрутизацией.

И найдя простое решение я решил упростить жизнь тем кто будет решать подобную задачу, но еще не имеет достаточного опыта для собственных экспериентов с маршрутами или не имеет времени на эти экспериенты.

Согласитель — когда задачу нужно решить «сейчас» никто не будет тратить несколько дней/недель на глубокое вникание в вопрос, а найдут инструкцию которая работает. В лучшем случае еще и «понятно работает». Инструкция с iptables хоть костыльна, но вполне понятна и на куче форумов рекомендуют именно её и почему-то не рекомендуют вариант правильной маршрутизации. Либо об этом мало кто знает, либо те кто знают уже не общаются на форумах, а просто знают и настраивают свои системы. Новичкам приходится использовать костыли.

Этой инструкцией в частности я предлагаю простой правильный путь массово предлагаемому костылю. Врядли это убивание ресурса.

Почему бы ещё не писать каждый полгода таториал по установке очередной версии убунту — тоже наверняка кто-то в поиске найдёт и прочитает, и оно будет востребовано. Однако, если постоянно идти на поводу востребованности большинством, то на выходе будет ширпотреб. Я не говорю, что это плохая стратегия, но применительно к этому ресурсу она убьёт его в текущем качестве.

Ну записал бы я себе это в локальный блокнот кому бы от этого лучше стало, кроме меня?

Возможно статья не идеальна, возвращаемся тому же, но другого я не нашел — покажите или изложите лучше.
Я почитал RFC о котором вы говорили, в нем описана общая теория, этот конкретный случай из неё не следует, к тому же практика настройки в нем не описывается вообще.

Что вы не вчера сети настраивать начали я в курсе, около месяца назад читал вашу статью о настройке mgre от 2009 года.

К сожалению в данном случае это невозможно: все пакеты наружу должны уходить с MAC-адреса интерфейса физического сервера, входящие тоже доставляются на MAC физического интерфейса.

Если рассматривать не конкретно этот случай, а случай локальной сети, то бридж откроет наружу всю локальную сеть, а не только один сервер который нужно открыть.