Сервер на сером ip

Удаленный доступ к компьютеру требуется для разных целей – посмотреть файлы, воспользоваться какой-либо установленной на компьютере программой (например — 1С, управление USB камерой и другое), распечатать документ на принтере и многое другое.

Но что делать, если компьютер расположен дома или в офисе, а удаленного доступа из сети Интернет туда нет?

Наша система VPNKI призвана помочь вам в решении этой задачи прямо сейчас.

Если вас интересует сама услуга по удаленному доступу к компьютеру, то, пожалуйста, перейдите сюда.

Об удаленном доступе

Причин в том, что у вас затруднен удаленный доступ к компьютеру может быть несколько и одна из них – отсутствие «белого» IP адреса, назначенного провайдером вашему оборудованию.

Что такое IP адрес и трансляция адресов (NAT) мы описали в предыдущей статье.

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

Представим себе несколько ситуаций:

• Первая – у вас есть белый (реальный) IP адрес, полученный от провайдера

Этот адрес прописан на внешнем интерфейсе вашего маршрутизатора. Например, этот адрес 1.1.1.1. В этом случае, вам необходимо настроить на своем маршрутизаторе правила "проброса портов" на устройства во внутренней сети. То есть, обращаясь из сети Интернет, например, по адресу 1.1.1.1 и порту 80 вы будете попадать на сервер «умного дома», расположенный во внутренней сети. А при обращении по адресу 1.1.1.1 и порту 3389 вы будете попадать на «удаленный рабочий стол компьютера с Windows» при помощи протокола RDP и программы-клиента в любом Windows-компьютере.

• Вторая ситуация – на внешнем интерфейсе вашего маршрутизатора прописан «серый» адрес из диапазонов частных сетей

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

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

Изнутри своей сети зайдите на сайт http://whatismyip.com и запишите ваш внешний адрес. Затем возьмите смартфон, отключите его от домашнего WiFi и воспользуйтесь сетью Интернет, но уже от оператора сотовой связи. В браузере смартфона наберите адрес, который вы записали. Если вы увидите ответ от вашего маршрутизатора, о том, что доступ запрещен или что-то подобное, то это означает, что ваш провайдер осуществляет трансляцию для входящего трафика. (обычно в сообщении об ошибке устройство пишет о себе что-то и вы узнаете свой маршрутизатор).

В этом случае, для организации удаленного доступа к компьютеру в домашней сети вы можете воспользоваться службой Dynamic DNS (например, no-ip.org). Получив доменное имя, вы сможете обращаться по нему из сети Интернет к своему маршрутизатору, а если вы настроите проброс портов, то сможете обращаться и к устройствам внутренней сети. Простейшим образом будет являться проброс порта TCP 3389 на компьютер с ОС Windows, установленный в домашней сети.

Также вы можете поднять свой собственный VPN сервер на своем маршрутизаторе и получить удаленный доступ не к одному компьютеру в своей сети, а ко всем устройствам сети.

Если обращение со смартфона по внешнему адресу не удалось — вы получили ответ о том, что заданный сервер недоступен или отвечающее устройство не является вашим маршрутизатором, то, скорее всего, ваш провайдер не осуществляет трансляцию адресов для входящего трафика. Тогда переходите к ознакомлению с вариантом 3.

• Третья ситуация – на внешнем интерфейсе вашего маршрутизатора «серый» IP адрес и обращение по нему из сети Интернет не приводит к успеху

В такой ситуации необходимо использовать любую внешнюю точку, которая позволит «объединить» соединения от ваших устройств – ведь исходящие соединения у вас устанавливаются успешно. Такой внешней точкой могут быть различные службы сети Интернет, включая широкоизвестные TeamViewer, Hamachi и другие.

Большинство из них создают «виртуальное соединение» от вашего компьютера с установленным приложением до сервера службы в сети Интернет. Такие туннели «объединяются» на сервере службы и пользователи имеют удаленный доступ к компьютеру. Однако, если нужно получить более широкий функционал, чем просто доступ к компьютеру через RDP или VNC вы можете использовать службу VPNKI.

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

Объединив свои устройства в единую сеть, вы сможете получить удаленный доступ не к одному компьютеру в своей сети, а ко всем устройствам сети по их внутренним IP адресам.

ДОПОЛНИТЕЛЬНО

Кроме базового функционала по объединению VPN туннелей с различными протоколами, в системе VPNKI вы можете воспользоваться удаленным доступом к компьютеру или камере, используя:

Довольно банальная ситуация — у вас нет возможности подключить проводной интернет с белым ip от нормального провайдера и приходится довольствоваться 4G от мобильных операторов. А выделенный ip очень нужен.

Это можно легко исправить. Допустим, у вас на работе белый ip и им никто не пользуется. При этом есть возможность поставить машину с linux на 24/7. Или же вы арендуете свой vps сервер. Главное чтобы был постоянный ip.

Я буду производить все манипуляции с системой на Ubuntu 16.04, которая выходит в интернет со своим собственным выделенным ip адресом. Домашняя сеть же крутится на роутере Keenetic Extra 2. Все действия заключаются в следующем: на сервере ставим OpenVPN, на роутере подключаемся к нему, перенаправляем порты на сервере, открываем порты на роутере. И все запросы будут проходить через сервер со статическим ip в нашу домашнюю сеть

У вас должен быть установлен Open VPN на Ubuntu 16.04, у меня есть на этот случай отдельная, очень простая инструкция

Теперь нужно подключить к vpn наш роутер.

В моем Keenetic Extra II это делается очень легко:

Переходим в Другие подключения

и сознаем новое, тип — OpenVPN:

Со всеми галочками, как на скриншоте.

Поле Конфигурация OpenVPN заполняем содержимым файла *.ovpn, сформированного на Ubuntu 16.04.

У меня кинетик не хотел подключаться к vpn, ругаясь в логе на 14 строку setenv opt block-outside-dns

Я ее удалил, кинетик подключился.

Теперь нужно настроить перенаправление портов на сервере в нашу домашнюю сеть.

Узнаем имеющиеся сетевые подключения командой:

нам нужно найти сетевой интерфейс с нашим белым ip:

В данном случае это eth0

и найти сетевой интерфейс vpn:

В данном случае это tun0

Теперь создадим сетевые правила для перенаправления из eth0 в tun0:

где 10.200.300.40 это ваш выделенный общедоступный ip, 10.2.0.3 это ip в сети vpn, выданный роутеру в файле *.ovpn, а 443 это порт, который мы перенаправляем.

Чтобы правила выполнялись и после перезагрузки сервера, отредактируем файл /etc/rc.local:

В автозапуск добавили, теперь откроем нужный порт на домашнем роутере.

В keenetic extra 2 переходим в Переадресация и добавляем правило:

Где вход это наше подключение vpn, а выход, это ваше устройство в домашней сети, куда нужно получить доступ. Ну и порты, естественно.

Вот и все, у нас есть постоянный ip адрес для доступа из интернета в домашнюю сеть

Ситуация следующая — имеется некоторый провайдер, который выдает только «серые» адреса. У клиента есть своя сетка, в которой работает NAS, несколько компьютеров, планшеты и т.п.

Требуется изредка каким-то образом подключаться к этой сетке для администрирования.

Понятно, если был бы «белый» адрес — можно было бы пробросить необходимые порты, поднять VPN-сервер на хранилище и т.п., а как быть с «серым» адресом?

Клиент в IT разбирается откровенно плохо, а находится далеко (т.е. вариант «подъехать» связан с авиаперелетом).

Подскажите, как можно осуществлять администрирование такой «недоступной» сетки?

• Вопрос задан более трёх лет назад
• 67633 просмотра

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

Спасибо всем, буду смотреть в сторону VPN.

Спасибо, думал про него, но для удобного варианта управления:
1. Нужно выделить под него какую-нибудь железку, которая будет всегда включена
2. Купить лицензию (чтобы без участия клиента можно было подключаться).

Рассматриваю этот вариант как запасной… может, еще какие-то варианты есть?

Чтобы все прояснить (поправьте, если в чем-то не прав).
Есть два понятия:

• Статический/Динамический IP — меняется ли он самопроизвольно (при подключении к провайдеру) или нет
• Серый/Белый IP — Серый IP — это адрес в локальной сети провайдера, аналогично 192.168.1.xxx, Белый IP — полноценный адрес в Интернет

Далее. Могут быть разные комбинации этих двух свойств. Самое главное, что, в общем случае, прямое подключение по Серому IP из Интернет не получится (без использования вспомогательного сервера с Белым IP). При этом прямое подключение к Динамическому Белому IP вполне возможно с использованием DynoDNS.

Оптимальный (но не самый простой) вариант решения проблемы с Серым IP — поднять VPN сервер на своем VDS, у которое есть Белый IP. Также, можно использовать различные платные и, возможно, бесплатные сервисы типа TeamViewer, Splashtop, LogMeIn-Hamachi, NetRouter, . (в зависимости от потребностей)

а так — все варианты связаны с железкой.

Это все просто и работало бы, если бы IP-адрес был бы реальным.

Вот, например, списочек адресов, которые засветились: 178.89.80.221, 178.89.82.93, 178.91.53.145, 178.91.53.173, 2.134.20.101, 2.134.20.159, 2.134.3.196, 95.58.101.131, 95.58.115.176, 95.58.115.51, 95.58.117.114, 95.58.124.112, 95.58.125.134

Ну дык у вас же IP не меняется каждую секунду, а только при переконекте, вы бы сначала ознакомились с тем, что такое DDNS, а уж затем меня минусовали.

На nas висит клиент, который при изменении IP отправляет этот самый IP на сервис DDNS, который в свою очередь работает как DNS, только указывает время кэша как 0, соотвественно другие DNS сервера данные не кэшируют и всегда запросы отправляют на DNS DDNS-сервиса.

Еще раз посмотрите на адреса? ничего не смущает? Это внутренние адреса провайдера, к которым нет доступа ни откуда, кроме как из сетки самого провайдера. Я же про это с самого начала говорю — «серые» адреса.

P.S. Динамические РЕАЛЬНЫЕ адреса меня ни сколько не смущают и как работает DDNS я знаю (и пользуюсь уже очень давно).

P.P.S. на моем собственном NAS висит DDNS на случай, если мой провайдер вдруг внезапно решит что-то перестроить в своей сети и сменить мой реальный IP (что уже один раз было и только из-за DDNS удалось оперативно получить доступ)

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

Как стукача можно использовать олдскульный iperf в режиме клиента, и пускать его скриптом (хоть на каждом компе клиента, а если у него Windows 7 или же UNIX-way операционки то скрипт можно прямо таки без проблем повесить на события подключения/отключения от сети, это как раз тот момент когда может произойти смена адреса).

С сервера вы всегда буде знать текущий IP, ходите сколько угодно.

VPN — тоже идея неплохая, все зависит от того насколько плотно Вам аутсорсить. Если на тачки по RDP/VNC ходить, то оно того не стоит,
ежели надо сеть тестить, внутренние сервисы и т.д. то, только VPN.

PS: У гада-провайдера может быть еще и магистральный NAT (хотя это уже история но в некоторых городах и весях я еще встречаю местные локалки которые наружу смотрят через прямой NAT провайдера, являясь там внутри — вполне себе обособленными, но это Ад и садомия и не обсуждается)