Настройки для серых ip

Возможно ли поднять веб-сервер на сером IP?

Всем привет! Меня интересует уже очень давно. Возможно ли поднять веб сервер на сером(динамическом) IP? И что бы он был доступен в интернете? Если да, то как?

Динамический ДНС-сервер не вариант?

А его можно на одном и том же сервере поднять?

А его можно на одном и том же сервере поднять?

Что значит на одном и тот же сервере? 🙂

И как это поможет в ситуации с глобально немаршрутизируемым адресом?

Так каков же на самом деле адрес: глобально не маршрутизируемый, динамический или же и тот, и другой?
Это вообще разные несвязанные понятия.

На сером (RFC1918) нет. На динамическом белом можно, dyndns выше советовали.

Еще локальный хост припомните. В данном случае, какого-нибудь DynDNS-а для ТСа будет явно достаточно, чтобы просто извне подрубаться к domain.dydnsserver.

У меня дома стоит компьютер и он на**г не кому не нужен. Обижает то, что он всего лишь один. Я хочу на нём веб поднять.

Всё вроде настроил. Всё работает. . на локалке. А теперь я хочу чтобы он был доступен в интернете, то есть любой пользователь мог написать домен и подключится к серверу. Домен если что стоит на REG уже. В DNS прописана A запись с IP моего сервера. Сижу думаю. Всё ли я так сделал? Или нужно свой DNS поднимать на одном и том же компьютере?

DynDNS загугли, инструкций море. По поводу IP уже сказали. Скинь что-ли результат ifconfig сюда.

И еще интересно, неужели у вашего провайдера статика стоит дороже 200 рублей доплаты в месяц? (хотя и это дофига ж).

Просто я очень страшный параноик. Щас попробую на no-ip с ddns поработать.

Не понял юмора. А как это успокоит вашу паранойю?

Человек путается в показаниях, и не факт что его IP не принадлежит к подсетям из rfc1918 или carrier-grade NAT. При чем тут локалхост?

Человек путается в показаниях, и не факт что его IP не принадлежит к подсетям из rfc1918

Вот уж не думал что в 2016 такое до сих пор используется 🙁

По белому IP меня быстрее найдут. Мне прятать если честно нечего. Просто очень не приятно.

Серый или динамический? Это разные понятия.

Ну по белому провайдер лучше знает кому он принадлежит.

Почему вы так думаете, и где вы об этом прочитали?

В 2016 (и вообще в последние годы) актуальность экономии адресного пространства у провайдеров выросла на порядки из-за подороожания блоков и жадности RIR, и как раз сейчас NAT все активнее используется даже у тех, кто раньше всегда давал глобальный маршрутизируемый адрес.

Ну по белому провайдер лучше знает кому он принадлежит.

Дак он по-любому IP это знает. Данные в любом случае проходят через него. Если бы он не знал что твой конкретный компьютер имеет определенный IP из «серых», куда бы он данные пускал? 🙂 А ты все равно зареган как клиент с определенным «клеймом», поэтому не все-ли равно какой IP?

В 2016 (и вообще в последние годы) актуальность экономии адресного пространства у провайдеров выросла на порядки из-за подороожания блоков и жадности RIR, и как раз сейчас NAT все активнее используется даже у тех, кто раньше всегда давал глобальный маршрутизируемый адрес.

Жесть, не знал такой инфы. Спасибо за ликбез. Значит проще сразу купить этот IP, если он реально нужен. Ну что эти 150-200 рублей по сравнению с остальными расходами 🙂 (у нас совсем 100 р у интерсвязи).

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

Плюс если меня забанят на каком-то сервере в какой-то онлайн игре по IP, то я больше не разбанюсь.

Почему? IP подменить можно в любом случае. Кстати как и MAC-адрес. Забил бы ты на это. Ну ты кстати так и не показал вывод ifconfig, поэтому не ясно что за адрес у тебя, но вангую что все таки из белых диапазонов.

Щас сервак подниму. Покажу.

можно, через Tor, будет домен типа .onion, соответственно, через Tor Browser и заходить на сайт.

enp2s12 Link encap:Ethernet HWaddr 00:15:e9:41:a2:dc inet addr:192.168.0.25 Bcast:192.168.0.255 Mask:255.255.255.0 inet6 addr: fe80::215:e9ff:fe41:a2dc/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:84 errors:0 dropped:0 overruns:0 frame:0 TX packets:126 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:11136 (11.1 KB) TX bytes:16178 (16.1 KB)

lo Link encap:Локальная петля (Loopback) inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:11 errors:0 dropped:0 overruns:0 frame:0 TX packets:11 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1 RX bytes:589 (589.0 B) TX bytes:589 (589.0 B)

Тьфу, точно из серого. Ну даже если вся сеть за натом сидит, пробуй DynDNS. Скорее всего от провайдера зависит.

Железка за домашним роутером? А на роутере какой ip от провайдера прилетает?

А сам провайдер не может такие IP выдавать? Ну вида 192.168.*.*?
Тут читаю на DynDNS, говорят во внешку нельзя при таком раскладе 🙁
http://forum.dyndnscommunity.com/forum/viewtopic.php?f=17&t=372

192.168.*.* локальный диапозон IP как правило. Провайдер их не выдаёт.

Может конечно, но у ТСа же несколько устройств, вряд-ли он каждое отдельно у провайдера подключал.

Что вообще за треш творится в этом треде?
Это технический ресурс о юникс-подобных системах или где?
Только Lavos задает нормальные вопросы и вообще разбирается в ситуации, остальные постят жуткий тупняк уровня ответы@mail.ru

Ну тогда если у тебя за чем-то сеть, то этот IP нам не интересен конечно. Естественно нужен IP от самого провайдера.

Конкретно и аргументированно. Что-за батхерт-то у вас? 🙂

Источник

Использование Wireguard клиентами с «серыми IP».

Официальный сайт:

Справка:

Это простое и высокопроизводительное средство создания туннелей с шифрованием трафика. Wireguard включён в состав ядра Linux под лицензией GPLv2. Передача пакетов осуществляется по протоколу UDP.

Благодаря продвинутому протоколу передачи данных и UDP, обладает высокой эффективностью преодоления NAT, что позволяет прокладывать туннели между пользователями с «серыми IP» (частными, внутренними), кроме случаев использования провайдером Symmetric NAT. При такой конфигурации сети потребуется хотя бы один участник с «белым IP» (выделенным) или применять туннелирование трафика сервером ретрансляции (TURN), имеющим выделенный IP.

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

В данной статье рассмотрен простой вариант соединения двух клиентов с «серыми IP», не спрятанными за Symmetric NAT.

Подготовка к работе.

Установка.

Для начала работы необходимо установить пакет wireguard-tools:

Основной состав пакета:

wg — основная программа.

wg-quick — программа для упрощения развёртывания туннелей по заранее заготовленным конфигурационным файлам. По умолчанию конфигурационные файлы располагаются в /etc/wireguard/. Файлы можно разместить в любой желаемом месте, но настоятельно рекомендуется строго ограничить права на чтение и запись, так как файл содержит информацию о закрытом ключе и списки IP клиентов, а так же считывается с правами суперпользователя. Есть незамысловатое правило: то, с чем работает суперпользователь, должно принадлежать суперпользователю.

Нюансы конфигурации «сервера» и «клиента».

Основные.

• Разница между сервером и клиентом довольно условна. Она заключается в том, что «сервер» должен знать всех «клиентов», а «клиентам» достаточно знать только «сервер», но нет никакой проблемы в том, чтобы все знали друг о друге. Последнее позволяет пользователям связываться друг с другом напрямую.
• Имя интерфейса Wireguard должно быть одинаковым у «сервера» и «клиентов».
• Имя зависит от названия конфигурационного файла. Если имя конфигурационного файла wg0.conf, то у интерфейса будет wg0. В целях безопасности имеет смысл задать собственное имя, а не предлагаемое по умолчанию.
• Выбор имени определённым образом ограничен, но без проблем можно называть подобным образом: wg-myVPN.conf
• По умолчанию файлы конфигурации хранятся в /etc/wireguard/. На деле место размещения файла конфигурации не имеет значения, но настоятельно рекомендуется строго ограничить права на чтение и запись, так как файл содержит информацию о закрытом ключе и списки IP клиентов, а так же считывается с правами суперпользователя. Поэтому имеет смысл дать право на чтение, запись и выполнение только суперпользователю, а всем остальным запретить всё.

О конфигурациях NAT и механике преодоления.

При использовании «серых IP» для установки соединения между клиентами нужно «пробить» NAT. Возможность «пробития» сильно зависит от конфигурации NAT на стороне провайдера: https://en.wikipedia.org/wiki/Network_address_translation#Methods_of_translation

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

Конфигурацию Symmetric NAT крайне проблематично преодолеть. Такой тип конфигурации повсеместно встречается у провайдеров мобильного интернета. Для преодоления потребуется участник сети Wireguard с выделенным IP (белым), через которого клиенты смогут соединяться между собой, так как прямое соединение между «серыми IP» при такой конфигурации крайне проблематично.

Пропуск трафика клиентов через участника сети с «белым IP» для установки соединения схож с использованием узла ретрансляции по протоколу TURN (для работы необходим сервер с выделенным IP).

Для пропуска трафика потребуется разрешить транзит пакетов по правилу FORWARD. Это можно сделать добавив строку net.ipv4.ip_forward=1 в файл /etc/sysctl.conf.

Для применения изменений:

Механика преодоления NAT заключается в следующем. Благодаря тому, что Wireguard использует UDP, роутер считает, что отправленный UDP-пакет по умолчанию достиг цели, сохраняет адрес и порт в таблице NAT в ожидании следующих пакетов, включая встречные. Тем самым это позволяет установить соединение, если пользователи знают свои реальные внешние IP (их получение описано далее).

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

Определение внешнего IP с помощью STUN.

Ключевым условием преодоления NAT является точное определение внешнего IP и порта, которые провайдер выделяет пользователям для соединения с узлами в интернете. Для надёжного определения внешнего IP и порта необходимо использовать STUN-сервер, так как изнутри сети провайдера свой внешний IP не определить.

Для использования STUN-серверов по протоколу RFC 3489 можно использовать Python-программу pystun3.

Установка (с правами пользователя):

Пример использования pystun3:

-H — указать адрес STUN-сервера. В данном случае это stun.nextcloud.com. Альтернативные адреса безопасных STUN-серверов: stun.ekiga.net, stun.sipgate.net.

-P — порт для соединения со STUN-сервером. Порт 3478 используется в качестве стандартного для обращения к STUN-серверу.

-p — порт, с которого будут отправлены пакеты в сторону STUN-сервера. В целях проверки выбрать порт, который планируется использовать для Wireguard. Стандартный порт Wireguard — 51820.

NAT Type: Full Cone
External IP: 80.235.76.174
External Port: 51820
Press any key to continue

Стоит сделать несколько попыток, чтобы точнее определить конфигурацию NAT.

В выводе указан внешний IP и порт, предоставленные провайдером для соединений с узлами в интернете:

• Совпадение указанного порта (51820) с внешним портом (External Port) указывает на высоковероятное использование конфигурации NAT вида Full Cone, которую Wireguard легко преодолевает.
• Если внешний порт отличается от указанного, то конфигурация соответствует Restric NAT, что заметно усложняет налаживание соединения между клиентами с «серыми IP». Важно учитывать, что провайдер предоставляет порт на ограниченное время. Если устойчивое соединение отсутствует, то через некоторое время (менее часа) провайдер сменит порт на другой. И так каждый раз. В этом основное усложнение установки соединения между клиентами с «серыми IP» для данного типа NAT. Используемый в Wireguard протокол и частота отправки пакетов с «рукопожатием» позволяют это преодолевать.
• Если порт (и/или IP) меняется при каждой попытке соединения со STUN-серверами, то, скорее всего, используется Symmetric NAT, что делает соединение между клиентами с «серыми IP» невозможным без применения ряда ухищрений.

Настройка конфигурации.

Генерация закрытого и открытого ключа.

Первым этапом настройки конфигурации является генерирование ключевой пары.

Примечание: Имена ключей могут быть любые.

Команда на генерацию представляет собой следующее:

umask 077 — применить маску прав для файлов, которые будут созданы в этой сессии терминала. 077 — разрешить пользователю чтение, запись и выполнение, а группе и остальным — запретить всё.

wg genkey — генерирует закрытый ключ. Затем вывод, содержащий сгенерированный ключ, перенаправляется (>) в файл private.key (будет создан).

wg pubkey — генерирует открытый ключ. Ввод ( ) перенаправляется в файл public.key.

По итогу получается два файла: private.key (закрытый ключ) и public.key (открытый ключ).

tee — утилита запишет ключ из буфера в файл с указанным именем (файл будет создан).

wg pubkey — закрытый ключ, который всё ещё находится в буфере, передаётся утилите pubkey, которая из закрытого ключа по алгоритму Base64 генерирует открытый ключ. Затем поток вывода (>) перенаправляется в файл с указанным именем (файл будет создан).

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

По желанию можно применить более строгий уровень прав на файлы ключей — только чтение:

Конфигурация «сервера».

Примечание: В конфигурационных файлах поддерживаются комментарии. Комментарий должен начинаться с символа #.

Пример конфигурации с одним клиентом:

Пример расположения файла:

Конфигурация «клиента».

Пример подключения к «серверу» без прочих «клиентов»:

Название файла должно быть такое же, как на «сервере» ( в примере wg0.conf), а расположение может быть любым.

Запуск Wireguard.

Упрощённый запуск с помощью wg-quick.

Утилита wg-quick входит в состав пакет wireguard-tools, установка которого описана в начале статьи.

Утилита на основе информации из файла конфигурации создаёт сетевой интерфейс Wireguard и запускает его. Пример запуска конфигурации «сервера»:

Вывод после выполнения команды:

В выводе перечислены команды, выполнение которых инициировала утилита wg-quick:

• Был создан сетевой интерфейс с именем wg0 и типом wireguard;
• Для него задействована конфигурация из файла wg0.conf;
• Присвоен IP, указанный в файле конфигурации;
• Установлено значение MTU;
• Для сетевого экрана применено правило, разрешающее прохождение пакетов с IP «клиента», указанного в файле конфигурации.

Имя интерфейса зависит от названия конфигурационного файла, в данном примере это wg0. У «сервера» и «клиента» интерфейсы должны называться одинаково.

Пример завершения работы интерфейса:

Были удалены интерфейс wg0 и правило для сетевого экрана, разрешающее прохождение пакетов с внешнего IP «клиента».

Так же можно включить создание и запуск интерфейса в виде автоматически запускаемой службы:

Проверка работы интерфейса и соединения.

Вывести информацию о сетевых интерфейсах Wireguard:

Проверка соединения к «серверу» по внутреннему IP созданной сети Wireguard (на примере IP ранее представленной конфигурации):

Проверка соединения к «клиенту»:

Отслеживать все пакеты, полученные или отправленные с указанного порта:

В лоб пропинговать весь диапазон IP, чтобы узнать IP всех участников сети:

Вывести доступный диапазон IP для указанного интерфейса:

После завершения работы интерфейса проверить правила iptables и убедиться, что правило на пропуск пакетов с внешнего IP было удалено:

Вывод должен быть пустым.

Проблемы с установкой соединения.

Если эхо-запрос (ping) не достигает пользователя сети Wireguard, то первым делом необходимо проверить не блокируются ли пакеты сетевым экраном (со стороны сервера и клиента):

Если блокируются, значит правило настроено неправильно. Ошибка может содержаться в имени основного сетевого интерфейса или во внешнем IP.

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

Если на роутере пользователя нет отброшенных пакетов с IP подключающейся стороны, то это может означать, что пакеты уничтожаются на роутере провайдера. Вероятно, неверно определён внешний IP или провайдер всё-таки использует Symmetric NAT. Во втором случае нет адекватных решений, кроме использования выделенного IP, включая вариант с ретрансляцией.

Источник