Подключение к компьютеру за nat провайдера
Есть компютер рабочий, который находиться за NAT. Нужно подключаться к нему в другой сессии, то есть не мешая пользователю. Кто пользовался RMS, там была функция подключения по рдп, но в RMS соеденение по рдп шло через их сервера, да и c недавнего времени RMS уже не работает.
И мне нужно, либо делать дедик из этого компа, но так как он за NAT то я пока не знаю как это сделать. Либо использовать сторонний софт, который позволяет подключаться в другой сесии. Аналогов тимвивера огромное количество, возможно кто-то подскажет какой софт имеет такую функцию. Или может есть такие ратники, в которых есть такая функция?
Как подключиться к RDP с внешки
Всем привет! Не закидывайте сразу гнилыми помидорами, я видел здесь темы с rdp, но все-равно не.
Два провайдера, два роутера (с NAT), как объединить всё это?
Есть два роутера, один с вайфаем, получает инет по выделенке (витая пара), другой ADSL. Инет в.
ip адрес при трансляции NAT провайдера
у меня несколько вопросов сразу, помогите разобраться, господа . Предистория. Роутер подведен к.
Как изменить GUID сетевого адаптера? Не могу подключиться к серверу по RDP
Добрый день! Возникла такая проблема, не могу понять в чем дело. Клиент (Win 7 pro) не может.
Не совсем понимаю.
Так обстоит дело?
1. Локальная сеть, муршрутизатор.
2. У Вас в локальной сети еще 1 маршрутизатор, который получает WAN от основного маршрутизатора и идет к рабочему вашему ПК ?
Не совсем понимаю.
Так обстоит дело?
1. Локальная сеть, муршрутизатор.
2. У Вас в локальной сети еще 1 маршрутизатор, который получает WAN от основного маршрутизатора и идет к рабочему вашему ПК ?
Все проще, компютер за натом от провайдера, ну и собственно за натом роутера. Никаких маршрутизаторов нет. Просто кабель от провайдера/роутер/комп. Могу кабель втыкнуть напрямую в комп, останется NAT от провайдера.
купить услугу "белый адрес" у isp, настроить перенаправление портов на роутере ИЛИ (лучше) поднять VPN-сервер, и подключаться к ПК через туннель
купить услугу "белый адрес" у isp, настроить перенаправление портов на роутере ИЛИ (лучше) поднять VPN-сервер, и подключаться к ПК через туннель
Не получиться. Компютер не домашний, а рабочий. Мне никто не даст этого делать. Я сказал что могу втыкнуть провод напрямую для прощего понимания, а так я бы пробросил порты и дал компютеру постоянный ipv4.
Но это все полюбом реально, потому что взять к примеру дедики которые продают, и я не говорю о тех которые брутят. Очень многие дедики за натом, а их все равно как-то настраивают и к ним можно законектится. Взять к примеру амазоновские дедики, они тоже за натом, потому что во первых когда подключаешся то ipv4 в виде 192.168.1.155, а во вторых, у них очень много дедиков, они не будут каждому брать белый айпи.
Но можно тогда предположить, что там куча учетных записей, и на самом деле все конектяться к одному и тому же деду, но к другой учетке, тогда ответом на этот вопрос будет, что - когда покупаешь амазоновский дедик, то это полюбом админка, а учетка всегда называется admin, если бы там было куча учеток, то вероятность того что мне будет попадатся вечно admin, сводиться к нулю. Так что настроить подключение к компу за натом возможно, но почему то об этом инфы толковой найти я так и не смог.
Статья о том, как мне удалось запустить VPN-сервер за NAT'ом домашнего провайдера (без белого IP-адреса). Сразу оговорюсь: что работоспособность данной реализация напрямую зависит от типа NAT используемого Вашим провайдером, а также роутером.
Итак, возникла у меня необходимость подключаться со своего Android-смартфона к домашнему компьютеру, оба девайса подключены к Интернету через провайдерские NAT'ы, плюсом компьютер подключен через домашний роутер, который тоже NAT'ил соединения.
Классическая схема с использованием арендованного VPS/VDS с белым IP-адресом, а также аренда белого IP-адреса у провайдера не рассматривалась по нескольким причинам.
С учетом опыта прошлых статей, проведя несколько опытов со STUNами и NAT'ами провайдеров. Решился на небольшой эксперимент, выполнив команду на домашнем роутере работающем на прошивке OpenWRT:
STUN client version 0.97
Primary: Independent Mapping, Independent Filter, random port, will hairpin
Return value is 0x000002
Дословный перевод:
Independent Mapping — независимое отображение
Independent Filter — независимый фильтр
random port — случайный порт
will hairpin — будет шпилька
Выполнив аналогичную команду на своем ПК, получил:
STUN client version 0.97
Primary: Independent Mapping, Port Dependent Filter, random port, will hairpin
Return value is 0x000006
Port Dependent Filter — порт зависимый фильтр
Разница в результатах вывода команд говорила о том, что домашний роутер вносил «свою лепту» в процесс трансляции пакетов из Интернета, это проявлялось в том, что при выполнении команды на компьютере:
я получал результат:
в это момент на некоторое время открывалась UDP-сессия, если в этот момент послать UDP-запрос (например: netcat XX.1XX.1X4.2XX 4398 -u), то запрос приходил на домашний роутер, что подтвердил TCPDump запущенный на нем, но запрос не доходил до компьютера — IPtables в качестве NAT-транслятора на роутере дропал его.
Но сам факт прохождения UDP запроса через провайдерский NAT давал надежду на успех. Так как роутер находится в моей юрисдикции, решил проблему перенаправлением UDP/11111 порта на компьютер:Тем самым получил возможность инициировать UDP-сессию и получать запросы из Интернета с любого IP-адреса. В этот момент запустил OpenVPN-server (предварительно сконфигурировав) слушая UDP/11111 порт, указал на смартфоне внешний IP-адрес и порт (XX.1XX.1X4.2XX:4398) и успешно подключился со смартфона к компьютеру. Но в данной реализации возникла проблема, нужно было как-то поддерживать UDP-сессию до момента подключения OpenVPN-клиента к серверу, вариант с периодическим запуском STUN-клиента мне не понравился — не хотелось впусту нагружать STUN-серверы.
Так же обратил внимание на запись "will hairpin — будет шпилька", данный режим
Hairpinning позволяет одной машине в локальной сети за NAT получить доступ к другой машине в той же сети по внешнему адресу маршрутизатора.
- запускал STUN-клиента с локальным портом 11111
- получал ответ с внешним IP-адресом и портом XX.1XX.1X4.2XX:4398
- отправлял данные с внешним IP-адресом и портом на почту (возможен любой другой сервис), настроенную на смартфоне
- запускал OpenVPN-сервер на компьютере с прослушкой UDP/11111 порта
- запускал OpenVPN-клиента на компьютере с указанием XX.1XX.1X4.2XX:4398 для подключения
- в любое время запускал OpenVPN-клиента на смартфоне с указанием IP-адреса и порта (в моем случае IP-адрес не менялся) для подключения
Практика
Написав пару скриптов, пару конфигурационных файлов, сгенерировав необходимые сертификаты (так как клиент на смартфоне работает только по сертификатам) получилась обычная реализация OpenVPN-сервера.
Основной скрипт на компьютере
Скрипт отправки данных на почту:
Конфигурационный файл сервера:
Конфигурационный файл клиента:
Генерация сертификатов производилась по этой статье.
Запуск скрипта:
Предварительно сделав его исполняемым
На стороне смартфона
Установив приложение OpenVPN для Android, скопировав конфигурационный файл, сертификаты и настроив его, получилось так:
В процессе написания статьи я перенес конфигурацию с компьютера на Raspberry Pi 3 и попробовал запустить всё это дело на LTE модеме, но не получилось! Результат команды
STUN client version 0.97
Primary: Independent Mapping, Port Dependent Filter, random port, will hairpin
Return value is 0x000006
значение Port Dependent Filter не позволило запуститься системе.
Но домашний провайдер без проблем дал запуститься системе на Raspberry Pi 3.
В связке с вэб-камерой, сVLC для
и VLC на смартфоне для просмотра (поток rtsp://10.2.0.1:8554/), получилась не плохая система видеонаблюдения на расстоянии, так же можно поднять Samba и обмениваться файлами, маршрутизировать трафик через VPN,
Вывод
Как показала практика, для организации VPN-сервера можно обойтись и без внешнего IP-адреса за который нужно платить, так же как и за арендуемый VPS/VDS. Но всё зависит от провайдера. Конечно хотелось получить больше информации о различных провайдерах и типах используемых NAT'ов, но ведь это только начало…
Спасибо за внимание!
В продолжение темы прохождения через NAT, вот краткий пересказ моих статей об управлении компьютером, который находится за NATом.
Фактически это описание бэкдора, поэтому убедитесь, что вы не нанесете вреда чужой сети и что локальные администраторы в курсе ваших манипуляций.
Задача: разместить линуксовый компьютер в сети за NATом, и иметь к нему доступ из внешнего мира. Например, вы траблшутите или поддерживаете что-то у клиента, и чтобы не сидеть у него в офисе, нужно быстро соорудить удаленный доступ. Или, например в 3G-сетях клиенты как правило получают приватные адреса, а нам нужен доступ к компьютеру, где другой связи нет.
2. Активируем keepalives на сервере и разрешаем GatewayPorts в /etc/ssh/sshd_config:
3. Создаем юзера comehome на сервере:
4. Удаленный компьютер — в принципе, любое устройство под линуксом. Назовем его agent01. Если у рута ещё нет SSH-ключей, создаем пару ключей командой ssh-keygen. Затем создаем скрипт /root/ssh_tunnel.sh:
в оригинальной статье есть также скрипт для /etc/init.d для автоматического запуска нашего туннеля.
5. Добавляем публичный ключ рута с agent01 в список авторизованных ключей на сервере, при этом не разрешаем агенту выполнять никаких команд. Также сообщяем агенту адрес порта, по которому он будет доступен (всё в одну строку):
Собственно, всё. Остается только протестировать. После запуска туннеля, SSH-соединение на порт 2101 должно приземляться на порту 22 удаленного компьютера.
Если агент — ноутбук под убунтой, начиная с убунты 12.04 невозможно отключить засыпание от закрытия крышки глобально (по крайней мере, мне не удавалось когда я последний раз тестировал).
Не забывайте сделать бэкап скриптов.
Убедитесь в том, что никто кроме вас не получит доступа к агенту, а также что на агенте четко написаны координаты владельца — вы же не хотите подставить чужую сеть под опасность.
В скрипте очень важны ServerAliveInterval (в случае разрыва соединения и клиент и сервер должны оборвать предыдущий туннель), а также sleep (без него при отсутсвии маршрута до сервера ssh возвращается мгновенно, так что лучше притормозить перед следующим запуском). StrictHostKeyChecking отключен на тот случай, если сервис callhome переедет на другую машину, а агент вне нашей физической досягаемости.
Статья о том, как мне удалось организовать прямой (точка-точка) VPN-туннель между двумя компьютерами, каждый из которых находился за NAT'ом провайдеров, при помощи VPS и простых скриптов, используя стандартные утилиты Linux, без каких-либо настроек сетевого оборудования.
Введение
Существует множество программ (TeamViewer, Hamachi) для удаленного управления компьютером, передачи данных и т.п. Работают они на удивление хорошо и в любых условиях. Но как правило это платные сервисы. Как устроены эти программы неизвестно, да и особого желания их использовать они у меня не вызывают. Я как пользователь ОС Linux (в основном Ubuntu) использовал для передачи данных и управлением своими ПК связку из OpenVPN, SSH, VNC, RDP и прочие сервисы в зависимости от потребности. Для того чтобы организовать сеть между двух компьютеров я использовал VPN-сервер, что бы эти компьютеры подключались к OpenVPN серверу и весь трафик шел через сервер. Это не совсем хорошо, ведь трафик проходит двойной путь, в следствии этого терялась скорость.
Классическая схема организации VPN-туннелей и передачи данных между узлами через сервер
Теория
Практика
Для решения этой задачи пришлось использовать VPS (S-синий овал), на нем я поднял скрипт который выполнял роль «Соединителя», что-то типа STUN-сервера: при помощи утилиты TCPDump получал UDP-пакет (далее везде используется UDP протокол) на определенный интерфейс и порт, парсил содержимое пакета, определял IP-адрес/порт источника и отвечал утилитой NetCat возвращая текущие параметры (IP-адрес и порт) соединения, а так же параметры (IP-адрес и порт) удаленного узла к которому нужно подключиться, если эти данные были доступны, иначе ждал пока они не появятся. Все это дело сопоставлялось с идентификатором (ID) соединения, так как несколько соединений могли мешать друг другу, при использовании ID все решалось. Также была проблема того, что узел получал свои же старые данные и пытался по ним подключиться и это решилось с помощью хеша Hostname.
На узлах A и B я использовал скрипт и сгенерированный заранее ключ для авторизации VPN-соединения, работало это так: запускался скрипт, случайно выбирался локальный порт в диапазоне от 20000 до 65000 и с этого порта отправлялся пакет на VPS, который содержал в себе ID соединения и хеш hostname, с помощью утилиты NetCat и тут же запускался TCPDump ожидая ответа. В ответ приходил пакет который содержал в себе текущие данные (IP-адрес/порт) этого узла, а при наличие данных удаленного узла, они тоже приходили и начинался обмен приветствиями между узлами. Если же данных удаленного узла не было, то опрос повторялся с периодичностью 30-45 секунд, для поддержания сессии. В момент когда все необходимые данные (IP-адрес и порт текущего узла и удаленного) были на узлах, начинался обмен пакетами, пакет содержал в себе число m=0 и сгенерированное число от 0 до 254 (это число использовалось для генерации внутреннего IP-адреса VPN-соединения). Удаленный узел получив пакет с m=0 отправлял в ответ m=1 и так далее до 10. При получении пакета m=10 инициировалась посылка пачки пакетов с периодичность в 1 секунду с m=13 и запуск OpenVPN, удаленный узел получив m=13 тоже запускал OpenVPN используя локальный порт, IP-адрес и порт удаленного узла, а также сгенерированный внутренний IP вида 10.X.X./30.
Схема прямого VPN-туннеля и передачи данных между узлами, без участия сервера
Внимание: скрипты написаны и проверены на ОС Ubuntu 18.04 и Debian 9
Скрипт на VPS:
Запускается автоматически строкой в /etc/rc.local
где 13013 — это порт который нужно слушать, /var/log/connector2.log — лог.
Скопировать скрипт в буфер и вставить в тектовый редактор, например:
Сделать скрипт исполняемым:
Для первого запуска сгенерируем ключ авторизации secret.key, на удаленной стороне генерировать не надо, нужно скопировать его:
Запустим скрипт, например так:
Запускается автоматически строкой в /etc/rc.local
где ID-соединения — это любая уникальная фраза для вашего соединения, /var/log/vpn7.log — лог соединения, ipsrv=«45.141.103.45» — IP-адрес узла где запущен connector2.sh (первый скрипт).
Если все настроено правильно, то будет работать как часы: включил и через пару минут у тебя есть связь с удаленным узлом. В скриптах используются бесконечные циклы и временные задержки, то есть скрипт работает пока включен узел и при потере связи будет пытаться восстановить её. Скрипты не идеальные но, сам факт того что эта технология работает дает мне массу новых идей, например:
- использовать узел для хранения особо важных данных, и иметь к ним доступ, допустим, в случае утери ноутбука все данные будут на узле
- использовать на ноутбуке удаленный рабочий стол компьютера
- организовать связи с компьютером друга и поиграть в сетевую игру
- иметь доступ к домашней камере видеонаблюдения с рабочего компьютера или просмотреть веб-камеру ноутбука
- простота в настройке и использовании
- трафик идет напрямую
- трафик шифруется и защищен от перехвата
- нет необходимости пробрасывать порты
- скрипт запускается автоматически
- главный недостаток это использования VPS как источника данных для соединения, но я думаю над этим
- некоторые провайдеры блокируют трафик между другими провайдерами (замечено у сотовых операторов)
- при использовании с обоих сторон одного провадера может не сработать, зависит от типа NAT
- при использовании провадером «жесткого» NAT может не сработать
Думаю на фоне дефицита белых IPv4 адресов моё решение будет актуально, ровно до тех пор, пока в каждый дом не придет IPv6.
- команда активации защиты от подмены адресов, уязвимость CVE-2019-14899
- команды завершающие зависшие процессы NC, ускоряется процесс установки соединения
- внутренние IP-адреса генерируются при первом запуске и их составляющие хранятся в vpn.cfg
Другая моя реализация VPN-туннеля, без использования VPS, с использованием STUN и Яндекс.Диска опубликована тут
Нельзя сказать, что задача удаленного доступа к устройствам в домашней локальной сети является очень распространенной и, вероятно, большая часть пользователей с ней даже никогда не встречалась. Однако все чаще в локальной сети появляются устройства и сервисы, с которыми хотелось бы работать удаленно. В качестве примера можно назвать сетевые накопители с библиотекой файлов, видеокамеры, устройства домашней автоматизации. В некоторых случаях может быть достаточно предоставляемых производителями собственных реализаций облачного доступа или даже просто проброса портов на роутере. Но если таких устройство много, существенно удобнее иметь возможность прямого обращения ко всей сети сразу, что может быть обеспечено сервисами VPN. Кроме того, этим технологии помогут и объединить две или несколько сетей в одну с прозрачным обменом данными между ними.
В данной публикации нет задачи максимально подробно рассказать про все распространенные протоколы VPN и их особенности. Сосредоточимся преимущественно на практической стороне вопроса сценария подключения удаленного клиента и попробуем сравнить разные варианты по удобству и производительности.
Сервисы VPN сегодня все чаще встречаются в прошивках беспроводных роутеров и, пожалуй, наибольшее их число представлено в решениях Keenetic, так что именно они и будут использованы в статье. Заметим, что если говорить именно о скорости, очень многое в данном случае зависит и от аппаратной платформы роутера и от программной реализации. Причем второй аспект может быть даже важнее. Кроме того, поскольку прошивки обычно закрытые, то и доступные через Web-интерфейс набор параметров серверов может отличаться. Влияние на производительность, конечно, оказывают и настройки сервисов. В данной статье я обычно использовал заданные производителем значения по умолчанию.
Также стоит отметить, что конкретно у решений Keenetic есть очень подробная база знаний на сайте, в статьях которой приводятся примеры настройки и использования дополнительных сервисов, включая все описанные в статье.
Текущая линейка продуктов компании основана на двух моделях процессоров (SoC) производства Mediatek – MT7628 и MT7621. На первом, имеющим одно вычислительное ядро, реализованы модели со 100 Мбит/с портами. Второй, с двумя ядрами, способными исполнять четыре потока, используется в устройствах с гигабитными портами. Более подробную информацию о конфигурациях устройств можно получить, например, в форуме iXBT.
Так что по сути, если взять по одному представителю на каждом чипе, можно охватить всю линейку роутеров компании в описываемой задаче, поскольку Wi-Fi, порты USB и объемы памяти здесь не существенны.
Для теста использовались устройства Keenetic City KN-1510 (младшая из двухдиапазонных) и Keenetic Ultra KN-1810 (старшая модель на данный момент).
Напомним, что прошивки у данного производителя модульные, так что в общем случае каждый пользователь может собрать свой уникальный вариант из требуемых сервисов и функций. Однако если для старших моделей с флешпамятью большой емкости можно не переживать про объем, то для младших ситуация существенно сложнее. В частности в данном тестировании приходилось добавлять на Keenetic City не более двух серверов за один раз. Кроме того, при анализе результатов не забываем, что эта модель имеет только 100 Мбит/с порты, что в определенных режимах будет выступать ограничением.
Все рассматриваемые в статье протоколы для своей работы в обязательном порядке требуют белого адреса на стороне сервера, что выглядит вполне логичным. Однако один из вариантов, благодаря специальным решениям Keenetic, можно использовать и без него.
Тестирование проводилось с прошивками версии 3.3.16. Режим подключения к Интернет – IPoE. В тестировании оценивалась скорость доступа внешнего клиента к компьютеру внутри локальной сети за роутером.
PPTP и L2TP
Одни из наиболее известных протоколов для реализации удаленного доступа – PPTP и L2TP. Первый уже считается небезопасным, хотя продолжает использоваться из-за невысокой требовательности к ресурсам. Заметим, что в нем предусмотрен как вариант без шифрования трафика, так и с ним. Одной из особенностей данного решения является использование специального протокола туннелирования, который часто бывает заблокирован домашними провайдерами, что приводит к невозможности использования данного типа подключения. Кроме того, используемые алгоритмы шифрования обычно не «ускоряются» специальными блоками в SoC.
Второй запомнился, прежде всего, использованием в сети одного из крупных отечественных провайдеров и отсутствием его поддержки у недорогих роутеров многих производителей.
Штатные клиенты для этих протоколов существуют во многих операционных системах, включая мобильные, что упрощает настройку подключения. Заметим, однако, что для L2TP обычно используется вариант L2TP/IPSec, в котором кроме привычного имени и пароля пользователя нужно также указать и общий ключ. Он и будет протестирован в этот раз.
Подключить сервисы несложно – после установки соответствующих модулей необходимо в меню «Управление» — «Приложения» включить серверы.
Из настроек предусмотрены разрешение нескольких одновременных входов для одного аккаунта, активация NAT для клиентов (они смогут выходить в Интернет через этот роутер), выбор IP-адресов для выделения клиентам и выбор сегмента сети для доступа.
Кроме того, для PPTP можно разрешить подключения без шифрования, а для L2TP/IPSec необходимо установить общий секретный ключ.
Оба сервиса позволяют запрограммировать в роутере несколько учетных записей пользователей и разрешить им доступ по VPN.
При настройке клиентов необходимо указать внешний адрес роутера (IP или имя хоста, что можно реализовать, например, через KeenDNS), аккаунт пользователя, для L2TP/IPSec – дополнительно общий секретный ключ. При работе с PPTP и штатным клиентом Windows необходимо учесть описанные в статье базы знаний особенности.
Для данных протоколов использовались штатные клиенты ОС Windows 10.
Keenetic City в PPTP без шифрования показывает близкие к скорости портов результаты. Хотя, вероятно, мало кого устроит незащищенное от перехвата данных подключение. Использование MPPE в PPTP снижает показатели примерно до 30 Мбит/с, что, в целом, очень неплохо для относительно недорогой модели (напомню, что сходные цифры будут и на самом младшем устройстве текущей линейки). Что касается L2TP/IPSec, то здесь можно рассчитывать не более чем на 10 Мбит/с, поскольку в данном случае применяется шифрование DES, а в Keenetic City оно не поддерживается аппаратно.
Заметно более мощная платформа Keenetic Ultra показывает и более высокие результаты: до 300 Мбит/с в PPTP без шифрования и в среднем около 80 Мбит/с в PPTP с шифрованием и L2TP/IPSec.
Итого мы видим, что данные реализации обеспечивают хорошую производительность, за исключением L2TP/IPSec на младшей модели, и просты в настройке благодаря стандартным клиентам.
OpenVPN
Следующий по распространенности в серверах домашних роутеров протокол VPN – OpenVPN. Благодаря реализации с открытым исходным кодом на базе библиотеки OpenSSL, данный протокол очень часто встречается в совершенно разных продуктах, а найти под него клиента не составляет труда для большинства операционных систем.
Данный сервис имеет очень гибкие настройки (включая режим работы, выбор опций шифрования, сертификаты, ключи, маршрутизация и так далее), которые обычно задаются в виде текстовых конфигурационных файлах. Это имеет и обратную сторону – новичкам может быть непросто настроить работу по данному протоколу. Но если говорить о Keenetic, то в статьях базы знаний можно скачать готовые конфигурационные файлы, в которых нужно будет только поменять адрес сервера. Впрочем, с точки зрения безопасности, безусловно, нужно будет сделать свои ключи или сертификаты.
Протокол использует через стандартные соединения TCP или UDP и позволяет выбрать порт. Так что работать с ним можно будет практически в любой ситуации.
В роутерах Keenetic нет отдельного пункта «сервер OpenVPN», данный тип соединений настраивается в разделе «Интернет» — «Другие подключения». Кроме того, потребуется настроить еще несколько опций в других местах (в частности правила для межсетевого экрана), а в некоторых случаях – и в консоли. На сайте поддержки Keenetic этому протоколу посвящено несколько подробных материалов. При определенном опыте, можно реализовать одновременное обслуживание сервером нескольких клиентов. Но это будет явно сложнее, чем простое добавление пользователей в общий список доступа. Для тестов использовался стандартный клиент для Windows с сайта OpenVPN.
По скорости на младшей модели мы получаем до 10 Мбит/с, а на старшей – примерно в два с половиной раза больше. Данный протокол, вероятно из-за своей гибкости, имеет определенные сложности работы через «ускорители», так что скорость работы принесена в жертву универсальности. Впрочем, на других SoC (в частности, топовых Broadcom) его реализация показывает в несколько раз более высокие результаты.
Данный вариант можно рекомендовать сторонникам открытого программного обеспечения и тем, кому требуется максимальная гибкость настройки сервисов. В плюсах также возможность работы по стандартным TCP/UDP соединениям и любым портам.
Реализация данного сервера в Keenetic интересна тем, что позволяет осуществлять удаленный доступ без белого адреса на роутере – через сервис Keenetic Cloud с шифрованием на всем пути. Заметим, что при работе через облако Keenetic Cloud, по своей сути, невозможно обеспечить гарантированную скорость доступа, поскольку нагрузка зависит от числа пользователей и их активности. В тестах использовалось прямое подключение и штатный клиент в Windows.
В целом результаты аналогичны предыдущему участнику – до 10 Мбит/с на младшей модели и до 30 Мбит/с на старшей.
IPSec
Эта группа протоколов, пожалуй, наиболее часто упоминается для решения задачи объединения сетей у «больших компаний на серьезном оборудовании». Основной проблемой при работе с IPSec для обычных пользователей является сложность настройки, так что на наш взгляд, его использование с домашним оборудованием является уделом хорошо подготовленных сотрудников ИТ-отделов или энтузиастов. С другой стороны, его реализация в Keenetic присутствует, а на сайте поддержки есть соответствующие статьи базы знаний. Потратив немного больше времени, чем с другими участниками, вполне можно настроить его работу со стандартным клиентом Windows.
Как и для OpenVPN, работа с IPSec осуществляется в разделе «Интернет» — «Другие подключения». Набор параметров явно не для новичка в сетевых технологиях. Нужно выбрать вариант идентификации, опции для двух фаз осуществления соединения, маршруты и так далее. Непросто настроить и соединение со стороны клиента. Можно конечно попробовать действовать «по картинкам», но если что-то пойдет не так, разобраться, не имея определенной базы знаний, будет сложно. Посмотрим, стоила ли игра свеч с точки зрения скорости.
Судя по результатам – вполне. Младшая модель способна обеспечить защищенное соединение со скоростью порядка 50 Мбит/с, а старшая работает в три раза быстрее. Да, конечно это решение не для всех, учитывая сложности настройки. Скорее данный тип соединения будет интересен для сценария объединения сетей, а не подключения удаленных клиентов.
Кстати, в прошивках Keenetic есть и специальный сервер IPSec (Virtual IP), который позволяет легко настроить доступ к роутеру и локальной сети за ним с мобильных устройств на Android и iOS через их штатные клиенты. В нем используется общий ключ и учетная запись пользователя. Остальные параметры установлены автоматичеки по требованиям совместимости с клиентами.
WireGuard
Еще один новый игрок в сегменте VPN-сервисов – протокол WireGuard. Можно сказать, что ему буквально на днях исполнилось два года. Он похож на OpenVPN по своему статусу программного обеспечения с открытым исходным кодом. При этом авторы WireGuard постарались сосредоточиться на использовании современных технологий и протоколов согласования ключей и шифрования и обойти узкие места других реализаций. Это позволило существенно сократить объем кода, оптимизировать скорость и реализовать решение в виде модуля для ядра Linux. В настоящий момент есть клиенты для всех распространенных операционных систем для компьютеров и мобильных устройств.
Сложность настройки в текущей реализации Keenetic можно оценить как среднюю. Сервис заводится в разделе «Интернет» — «Другие подключения» и позволяет также объединять сети, а не только подключать удаленных клиентов. Сначала производится генерация пары ключей (закрытого и публичного) для сервера. На тоже клиенте будет проведена аналогичная операция. В настройках пиров нужно будет указывать публичные ключи второй стороны. Также на стороне роутера присутствует выбор номера порта, подсетей и другие параметры. В случае вопросов, лучше обратиться на сайт поддержки Keenetic, где описаны процедура настройки этого сервиса. Кроме того, потребуется настройка правил межсетевого экрана и маршрутизации. В случае необходимости выхода удаленного клиента в Интернет через роутер нужно будет поработать и в консоли. В фирменном клиенте для Windows конфигурация задается в виде текстового файла. Параметры аналогичны настройкам в роутере. При необходимости на стороне сервера можно запрограммировать несколько пиров, что позволит одному серверу обслуживать одновременно несколько клиентов.
Тестирование показало, что данных протокол выступает по скорости очень хорошо и его результаты сравнимы с традиционным IPSec. Младшая модель способна показать 40-50 Мбит/с, а старшая – 150-220 Мбит/с.
На наш взгляд, это очень неплохое начало. Если бы еще немного упростить конфигурацию (например, создавать все требуемые настройки на стороне роутера, так что пользователю останется только скачать готовый файл настроек и импортировать его на клиенте), то будет и удобно, и быстро, и безопасно.
Заключение
Все рассмотренные протоколы удаленного доступа имеют свои уникальные особенности и выбор будет зависеть от условий и требований пользователя, включая уровень подготовки и тип операционной системы на клиенте. С точки зрения простоты настройки оптимальным универсальным вариантом можно считать L2TP/IPSec. Однако на младших моделях он все-таки небыстрый, так что и PPTP найдется место. SSTP имеет смысл в случае отсутствия белого адреса на роутере. Если же хочется скорости, то стоит посмотреть в сторону WireGuard, но нужно будет потратить немного больше времени на настройку. OpenVPN и IPSec выберут те, кто уже знаком с этими протоколами и умеет с ними обращаться.
Читайте также: