Redirect gateway def1 bypass dhcp

Redirect gateway def1 bypass dhcp

Да, этот вопрос задавали сто раз, и я искал везде, безрезультатно.

В названии говорится, что все действительно.

У меня есть сервер OpenVPN (On ubuntu), и я могу подключиться к нему через мой клиент (Windows 8) .

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

Я добавил флаги push в server.conf:

Когда я подключаюсь к клиенту, клиент выдает:

Я попытался использовать флаги на стороне клиента при открытии соединения:

Но все же, когда я перехожу на whatsmyip.org, он все еще говорит, что мои клиенты ip.

У кого-нибудь была эта проблема и удалось ее решить?

5 ответов

Я протестировал это с помощью сервера OpenVPN и установил опцию def1 для перенаправления-шлюза в конфигурации клиента и сервера. Когда я обращаюсь к whatismyip.org , я вижу свой IP-адрес сервера OpenVPN. Ниже приведена конфигурация клиента, которую я использую:

Я также тестировал с добавлением опции redirect-gateway def1 в команду openvpn и добился такого же результата. Конфигурация сервера:

Возможно, вы забыли изменить свой NAT? Запустите эти 3 команды как root

  • tun0: ваша виртуальная сетевая карта VPN
  • eth0: обычная сетевая карта
  • 10.8.0.0: ваш IP-блок VPN сети.

После трудного поиска ответа кажется, что я решил это, может быть, частично, но, по крайней мере, очень просто:

Я использую пакет Xubuntu 14.04 и OpenVPN из основного источника. В Настройки > Система > Сеть , я заменил предварительно установленный DNS-адрес 127.0.1.1 % Google 8.8.8.8 , и теперь я вижу весь трафик, проходящий через VPN-сервер.

В таблице Wireshark такая строка, как DNS, отсутствует: все данные идут как TCP через зашифрованный канал. Я вижу DHCP и DNS-трафик, когда смотрю tun0 (внутренняя часть ноутбука). Когда я просматриваю wlan0 трафика (внешний между ноутбуком и WiFi-маршрутизатором), я получаю только серые пакеты TCP.

Я думаю, что это происходит, потому что DNS-запрос не требуется в декодировании символов к номерам, и он идет в общем потоке, как обычный пакет данных.

Я буду рад узнать ваши соображения, это не будет неожиданностью, если я полностью ошибаюсь

Добавьте следующую директиву в файл конфигурации сервера:

Если ваша настройка VPN выполняется по беспроводной сети, где все клиенты и сервер находятся в одной и той же беспроводной подсети, добавьте локальный флаг:

Нажатие опции redirect-gateway для клиентов приведет к тому, что весь трафик сети IP, происходящий на клиентских компьютерах, пройдет через сервер OpenVPN. Сервер должен быть настроен так или иначе обрабатывать этот трафик, например, посредством NAT-подключения к Интернету или маршрутизации через HTTP-прокси сервера сайта.

В Linux вы можете использовать такую команду для NAT-трафика VPN-клиента в Интернете:

Эта команда предполагает, что подсеть VPN 10.8.0.0/24 (взята из директивы сервера в конфигурации сервера OpenVPN) и что локальный интерфейс ethernet — eth0.

Когда используется перенаправление-шлюз, клиенты OpenVPN будут маршрутизировать DNS-запросы через VPN, и VPN-серверу потребуется обработать их. Это может быть достигнуто путем нажатия адреса DNS-сервера на подключение клиентов, которое заменит их обычные настройки DNS-сервера за время, когда VPN активен. Например:

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

Зачем нужен VPN-туннель? Ясное дело — связать две приватные подсети друг с другом через интернет. А если подсетей, допустим не две, а пять? Что делать в этом случае? Как можно, как лучше? Мои размышления на эту тему с конкретным примером реализации. Пример основан на программных средствах, с минимумом вложений.

Предисловие

Статья была написана почти 3 года назад. Спец по сетям из меня тогда был аховый, больше "сервачник" и "виндусятник". Сейчас, в 2019 сказал бы, давайте мне цисок, DMVPN вам замучу. Но тогда я просто этого не умел. Никах средств и никакого оборудования мне никто выделять не собирался. Да и никто не воспринял мою затею всерьёз. Всё что мне было позволено — создать несколько виртуальных машин на имеющихся серверах, да ещё в моём распоряжении была неиспользуемая мини рабочая станция HP. Но я попробовал, результат получился на удивление изящный и дешёвый, сам удивляюсь:

  • Абонентка 500 рублей в месяц за VPS-сервер;
  • Потом уже, когда система заработала и была обкатана, купили 2 Raspberry Pi 3;
  • Стабильная работа и keep alive
Чуть теории

На данный момент соединение сетей с помощью VPN туннелей является самым популярным способом в первую очередь потому, что требует минимум начальных вложений в создание инфраструктуры и никаких ежемесячных платежей за аренду (500 рублей в месяц для организации это просто ничто, поэтому не считаем), за трафик или ещё что-то — носителем выступает условно-бесплатная среда интернета. Минус в этом же — маршрут движения пакетов непостоянен во времени и как следствие непостоянна задержка между шлюзами туннеля. Чем дальше территориально разнесены сети, тем более возрастает нестабильность фактора задержки в течение рабочего дня.

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

Выбор топологии

Итак, несколько подсетей. Для начала нужно проверить, что они не перекрываются. При всей очевидности проверить все-таки надо. Вот скажите сходу перекрываются ли сети?

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

Полносвязное соединение

Все элементы равнозначны.

Плюсы:

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

Минусы:

  • При большом количестве сетей избыточная, громоздкая структура;
  • Добавление новой сети требует настройки еще стольких новых туннелей, сколько подсетей уже имеется (либо DMVPN);
  • Если одна сеть (филиал организации) переезжает по новому адресу, то это требует полной перенастройки всех связанных с ней туннелей.
Звезда

Ядро системы настраивается как VPN сервер, остальные элементы как VPN клиенты.

Плюсы:

  • VPN клиент может находиться за NAT. IP адрес он может получать по DHCP. Это делает такого клиента непривязанным к конкретной сети провайдера. Включаем его на новом месте, он подсоединяется к серверу и работает. Всё что нужно сделать, это кинуть на него маршрут;
  • Простота добавления нового клиента — минимальная настройка на сервере, а сам клиент настраивается из типового шаблона;
  • Если клиент реализован на виртуальной машине, то это бесплатно. Вычислительная мощность такого клиента настраивается за минуту в любую сторону;
  • Неочевидный плюс безопасности: маршрут на клиент, выступающий в роли шлюза в туннель, можно прописать как для всей локальной сети, так и для отдельных узлов;
  • Второй неочевидный плюс безопасности: анонимность — с клиентов остальные подсети видятся только по своим приватным адресам, а если вдобавок на vpn-сервере выключен лог, то даже получив доступ к нему невозможно собрать информацию кто и откуда подключался;
  • Третий неочевидный плюс безопасности: если локальная подсеть клиента маленькая, либо же малое число клиентов в сети использует туннель, то в этом случае клиент можно реализовать на микрокомпьютере Raspberry Pi. При необходимости такой микрокомпьютер можно здорово запрятать, а при настройке соединения через Wi-Fi и вовсе его не найдешь;
  • Четвертый неочевидный плюс безопасности: всю структуру можно выключить, выключив VPN сервер. Если при этом VPN сервер реализован как VPS в интернете, то сделать это можно, находясь где угодно, одним нажатием на смартфоне. Если хостер разумно-жадный, что в данном случае хорошо и не делает бесплатных бекапов, то и полностью удалить VPN сервер без всяких следов можно также легко.
Читайте также:  Юстировка объектива sigma в москве

Минусы:

  • Единая точка отказа, если VPN сервер недоступен по каким-либо причинам, то вся сеть лежит;
  • Для каждого клиента нужны либо виртуальная машина, либо машина физическая;
  • Размещенный в интернете VPN сервер требует ежемесячной оплаты;
  • VPN сервер должен обладать необходимой вычислительной мощностью чтобы покрывать обсчет трафика от клиентов. Теоретически при достаточно большом количестве клиентов и больших подсетях за клиентами этой мощности может не хватить. На практике такого никогда не случится.
Реализация

Сначала хотел сделать что-то, взяв готовые решения типа IpCop, но потом понял, что из этого ничего не получится. Заставить тестового Ubuntu-клиента приконнектиться к серверу не удалось. Несмотря на стандарт, реализация Openvpn видимо везде разная, например openvpn-сервер на роутере Mikrotik RB2011U почему-то использует TCP.. ( //voxlink.ru/kb/voip-devices-configuration/Conf_openVPN_windows_after_openVPN_Mikrotik/ ). Это видно из строки proto tcp-client. Роутер Mikrotik в режиме клиента непонятно что использует, но к готовой реализации проекта он также не подключился. Может что-то не разобрал, не спорю, тем не менее в конце-концов, ещё задолго до заказа VPS, пришел к выводу, что придется всё настраивать с нуля на одной ОС для всех машин туннеля.

По многим причинам выбрал вариант с выделенным VPS в интернете. Для начала нужно определиться где, в каком дата-центре разместить VPN сервер. Для этого нужно попросить в поддержке интересующего дата-центра тестовый IP, попинговать его и сделать трассировку из всех предполагаемых к соединению сетей, посмотреть число хопов. Полезная программа WinMTR:

Это занимает определенное время и вот наконец дата-центр выбран, VPS оплачен и готов к настройке.

Настройка VPN-сервера

Используем Ubuntu 16.04 LTS как дружелюбную, хорошо отлаженную систему. Установить систему на VPS можно из предварительно настроенных образов хостера, либо же отписать в поддержку и попросить загрузить для установки свой дистрибутив — А у вас нет такого же, но с перламутровыми пуговицами? Не стал заморачиваться и взял то, что дают. Установил, установка занимает пару минут: root включен, ssh доступ root включен, swap раздела нет. Последнее не очень хорошо, поэтому первое:

Меняем hostname, когда сидишь через ssh сразу на нескольких машинах, то можно легко запутаться и набумбасить лишнего там, где не надо, потом будет обидно, а если отвалится связь с машиной, то очень обидно, поэтому:

Своих клиентов обозвал по порядку V1, V2, V3 и так далее.

Убираем автообновление, вредная штука:

Меняем root пароль:

Также полезно пользоваться командой history для просмотра истории команд.

Настройка Openvpn и сертификатов

Копируем дефолтный конфиг Openvpn для правки:

Конфиг

Все понятно, наиболее важные параметры:

Разрешаем форвардинг пакетов, полученных с других машин. Вот тут я долго не мог понять почему с клиента пакеты через туннель ходят, а пакеты отправленные с хостов на клиент лезут в интернет, вместо того чтобы лезть в туннель:

Файрвол

Файрвол по умолчанию выключен. Настраиваем:

Генерация сертификатов сервера

Данное действо происходит довольно долго и зависит от мощности сервера.

Переходим непосредственно к генерации ключей сервера:

Будут сгенерированы сертификат удостоверяющего центра и сертификат и ключ сервера — ca.crt, server.crt, server.key, все их нужно скопировать в папку /etc/openvpn:

Проверим, что все на месте:

Запускаем сервис и проверяем его статус:

Если само не возвращается в привилегированный режим, то жмем Ctrl-C.

Генерация сертификатов клиентов

Совет — генерируйте сразу на пару клиентских сертификатов больше, чем нужно, с запасом.

Для заливки/скачивания с машины файлов есть очень удобная программа WinSCP.exe

Копируем ключи с сервера с помощью WinSCP.exe на свою локальную машину. Для каждого клиента X должен быть наборчик — ca.crt, clientX.crt, clientX.key.

Параметры сервера для каждого клиента

В конфиге сервера есть строчки:

Они говорят что дополнительные параметры клиентов хранятся в директории ccd и для каждого клиента доступны свои эксклюзивные параметры. Создаем указанную директорию и файлы параметров:

Редактируем каждый файл параметров:

Первая строчка говорит, что шлюз туннеля на клиенте один получит адрес 10.8.0.6, вторая обратный маршрут — маршрут с VPN сервера в подсеть клиента один. После настройки всех файлов параметров:

Немного о подсетях для туннеля

Каждый туннель это соединение point-to-point, в котором используется подсеть на 4 адреса. Такая подсесть имеет маску /30, то есть 255.255.255.252, а количество адресов вычисляется по формуле 2^n , где n = 32 — количество бит маски, поэтому адресов для маски /30:

Но первый адрес — это адрес всей подсети, последний — широковещательный адрес этой подсети, поэтому для назначения узлам доступно только два адреса — второй и третий по счету. Формула тут уже 2^n-2 и для наших подсетей это равно двум. Считать очень легко, группами по четыре ( 0,1,2,3 — 4,5,6,7 — 8,9,10,11 — 12,13,14,15 — 16,17,18,19 — . — 252,253,254,255 ):

Легко можно посчитать, что максимум клиентов при такой конфигурации 256/4 — 1 = 63, то есть больше, чем когда-либо понадобится (минус 1, потому что 1 подсеть использована для сервера).

На этом, чтобы не усложнять, с сервером пока всё.

Настройка клиента

Для клиентов официальный дистрибутив Ubuntu-Server x64 со страницы проекта, в качестве носителя — виртуальная машина, получение настроек сети — по умолчанию (от DHCP). Виртуальная машина идеально подходит для экспериментов, создаем контрольную точку и по необходимости откатываемся на неё столько раз, сколько надо. Создание нового клиента также идеально на виртуальной машине — предварительно настроенная болванка машины выкладывается куда-нибудь на Яндекс Диск и люди с той стороны её забирают, включают на своем Hyper-V и всё работает.

После установки включаем root’а:

Включаем вход root по ssh:

Переключаемся на root и убиваем текущего пользователя, созданного при установке:

Далее кратенько, так как почти все уже делалось на сервере:

Файрвол не включаем, клиент за NAT, нет необходимости.

Конфиг
Ключи

Копируем ключи, проверяем что все на месте, стартуем Openvpn, проверяем статус туннеля:

Если все нормально, то будет так:

На этом с основной настройкой всё.

Скрип авто-поднятия туннеля на клиентах

Дело в том, что если туннель на работающем клиенте по каким-то причинам упадёт, то сам он не поднимется до перезапуска сервиса или до перезагрузки клиента, поэтому лепим скрипт, делаем его исполняемым и ставим его в Cron:

Если туннель не найден среди активных интерфейсов, то время пишется в файл openvpn.bug.

Проверка идет каждые 3 минуты, этого достаточно, так как перезапуск службы и подъём туннеля происходит мгновенно.

Синхронизация времени

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

Установить временную зону:

Проверить время можно так:

Сервер

Чтобы с NTP-сервером могли синхронизироваться машины из локальной сети:

Служба синхронизации времени использует порт 123 для соединения с сервером, поэтому необходимо разрешить доступ:

Окончательный вид файрвола сервера:

Клиенты

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

Читайте также:  Как вставить текст из буфера обмена андроид
Основные маршруты

Чтобы все машины подсети клиента, речь идёт о Windows машинах, могли ходить в туннель и видеть подсети за туннелем накидываем маршруты для этих подсетей на местный офисный роутер. Если же это нужно только для отдельных машин, то прописываем маршруты на каждой из них, пример для 1 маршрута и соответственно для 1 удалённой подсети:

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

Как добавить постоянный маршрут на Ubuntu машину рассказано в отдельной записи.

Дополнительные маршруты

А что если на одном или нескольких клиентах есть больше чем одна подсеть? К примеру у меня в центральном офисе за напрямую подключенной к клиенту сетью 192.168.0.0/20, есть еще 10.50.0.0/20. Эта сеть находится за роутером и маршрута в эту сеть на клиенте центрального офиса нет, он ничего про неё не знает. Нужно прописать 4 маршрута — 3 прямых и 1 обратный. То есть сеть 10.50.0.0/20 прописывается:

  • На клиенте центрального офиса V3;
  • В файле sever.conf на vpn-сервере:
  • В файле параметров клиента на vpn-сервере:
  • И в подсети другого клиента, где сеть 10.50.0.0/24 должна быть доступна, на роутере или на хостах.
Клиент — физическая машина

Админов можно классифицировать по разным признакам, один из признаков — админы, как и коты, бывают ленивые и очень ленивые. Умные дядьки с хорошими зарплатами из центрального офиса сказали, что поднять Hyper-V сервер — это невозможная задача и времени надо как минимум до середины ноября, поэтому готовую виртуальную машину пришлось заливать на физическую и передавать уже в таком виде. Процесс описан в отдельной записи. Ещё надо не забыть включить в BIOS машины опцию Power On After Power Fail.

Клиент — Raspberry Pi 3

Начиная с третьей версии Малинка поддерживает Ubuntu. Два дистрибутива, что я нашел — не заработали. Дистрибутив с официальной страницы после обновления стал вываливаться в дамп. Второй дистрибутив с "raspberry2" в названии вообще не стартовал. Поставил Raspbian. Это моё первое знакомство с данной ОС. Логин/пароль по умолчанию pi/raspberry. Практически все команды работают, Debian он и есть.. — установить vim и команды задавать как vim . Не нашел как отключить автоматическое обновление (а включено ли оно вообще?). Всё остальное также как и для других клиентов — включить root, убить пользователя pi и так далее. Рассмотрение настройки Малинки не входит в задачи этой статьи. Очень-очень кратко:

Добавление нового клиента

Через некоторое время потребуется добавить нового клиента. Генерим новые сертификаты на сервере:

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

Прописываем новую сеть в конфигурацию сервера server.conf, создаем файл параметров клиента в папке ccd. Берем болванку виртуальной машины и заливаем сертификаты, а старые удаляем. В начале этого процесса лучше изолировать машину от выхода в интернет, иначе она полезет к серверу и нарушит работу машины, с которой была снята эта болванка.

Подключение к клиентам

После прописывания основных маршрутов все клиенты доступны по SSH через туннель по своим адресам в туннеле — 10.8.0.X.

Заключение

Чего-то много опять получилось, реально статья — 5300+ слов. Наверное половину слов дают конфиги 🙂 А на написание и правку так вообще целый день ушел, больше даже, но написание подобных статей хорошо систематизирует знания. Openvpn сеть работает и чем дольше пользуюсь, тем больше мне нравится. Приятно, что открытое ПО стало уже таким зрелым и вкусным.

Единственный момент, который был упущен из виду MTU на сервере и на клиентах. Хотя при настройках по умолчанию всё работало нормально. Кто хочет поразбираться с данным моментом, можно почитать на OpenVPN Wiki, поиск по ключу "mssfix".

Строим сеть Openvpn: 8 комментариев

/etc/default/ufw
DEFAULT_FORWARD_POLICY="ACCEPT"
слишком координально.
лучше добавить правило, например:
ufw route allow from 10.8.0.0/24 to 192.168.0.0/24
хотя и это многовато.. 🙂

Андрей, спасибо за комментарий. Учту.

Так, ещё раз всё проверил, что-то вы путаете. http://help.ubuntu.ru/wiki/руководство_по_ubuntu_server/безопасность/firewall
Цитирую: 1. Во-первых, в ufw должно быть активировано перенаправление. Для этого нужно изменить конфигурацию двух файлов, в /etc/default/ufw измените DEFAULT_FORWARD_POLICY на “ACCEPT”
И посмотрите в статье "Окончательный вид файрвола сервера:". Там мы видим, что разрешён трафик ssh отовсюду — он защищён паролем и сертификатом, разрешён трафик openvpn отовсюду — подключатся лишь клиенты с верным сертификатом и разрешен трафик NTP из внутренней сети. Никаких проблем в безопасности нет, DEFAULT_FORWARD_POLICY “ACCEPT” всего лишь правило по-умолчанию, без которого вообще никакой форвардинг пакетов через сервер невозможен.

Возможно что то путаю, но у меня работает с DROP по умолчанию и правилом ufw route. Я это понимают так. Если openvpn сервер находится в локалке то да можно так
/etc/default/ufw
DEFAULT_FORWARD_POLICY="ACCEPT"
Правило по умолчанию: Если не запрещено то куда угодно.
В такой ситуации даже ufw disable не слишком опасно, но если на интернет шлюзе то лучше всетаки "DROP" и правило
ufw route allow from 10.8.0.0/24 to 192.168.0.0/24
(хотя и там лучше ограничить порты и протоколы до необходимых) — разрешает маршрутизацию только между подсетями 10.8.0 и 192.168.0
На help.ubuntu.ru хорший мануал, но там эту проблему решают както непосредсвенно через iptable.. для меня слишком умно ))), а ufw route почемуто забыли.. см. man ufw
Сама маршрутизация включается действительно в /etc/ufw/sysctl.conf :
net/ipv4/ip_forward=1
в Windows c помощью regedit кажется так:
HKLMSYSTEMCurrentControlSetServicesTcpipParameters для параметра IPEnableRouter на “1” и перезагрузить.

Насколько понимаю в силу своего разумения — ufw закрывает не только трафик снаружи, но и внутри машины, а именно между сетевыми интерфейсами, если их несколько.
DEFAULT_INPUT_POLICY="DROP"
DEFAULT_OUTPUT_POLICY="ACCEPT"
DEFAULT_FORWARD_POLICY="DROP"
DEFAULT_APPLICATION_POLICY="SKIP"
Вот чтобы интерфейсы имели возможность пересылать между собой трафик и нужно правило DEFAULT_FORWARD_POLICY="ACCEPT" и больше ни для чего, и больше ни на что оно не влияет. Можно его сделать DROP и точно указать с какого интерфейса на какой разрешено пересылать трафик? Да можно конечно. А зачем? Ведь это внутри машины всё. Зачем трафик внутри машины нагружать обсчётом? На это тратятся ресурсы. Считаю неоптимальным решением.

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

Спасибо за комментарии, пришлось посидеть, поразбираться с устройством файрвола в Linux. Уже хорошо 🙂 Также чётче обозначилась необходимость закончить LPIC-1, потому что знаний курса Essentials, который пройдён на момент, явно недостаточно и довольно несложная вещь (как вопрос, который мы обсуждали) сначала превращается в гадание на кофейной гуще, а потом в высиживание интернета в поисках ответов — это про себя говорю. Надеюсь, вы тоже получили какую-то пользу от нашего обсуждения.

Да точно в linux для включения маршрутизации нужно еще echo 1 > /proc/sys/net/ipv4/ip_forward

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

Инструкция для Debian, но не думаю что будет что-то сильно отличаться на FreeBSD.
Установка и настройка сервера

Входим на сервер и устанавливаем OpenVPN:

Создаем файл /etc/openvpn/server.conf со следующим содержимым:

А теперь поясню параметры:

  • mode server — означает, что OpenVPN будет работать в режим сервера;
  • daemon - указываем что будет работать в режиме демона, stderr/stdout будет посылаться в syslog;
  • local 203.0.113.42 — можете указать конкретный IP-адрес на котором надо слушать (например если у вас несколько внешних сетевых интерфесов);
  • port 1194 — порт который будет слушать;
  • proto udp — будем использовать UDP, так как он экономичнее по трафику, вы можете также указать "tcp";
  • dev tun — использовать управляемый IP-туннель, также возможно использовать "tap" (ethernet tunnel);
  • ca ca.crt — путь до сгенерированного нами файла корневого сертификата;
  • cert server.crt — путь до сгенерированного нами файла сертификат сервера;
  • key server.key — путь до сгенерированного нами файла приватного ключа сервера;
  • dh dh2048.pem — путь до сгенерированного нами файла с параметрами Diffie Hellman (используется только для подключения через TLS-сервер);
  • tls-server — включаем TLS и во время handshake представиться сервером;
  • tls-auth ta.key 0 — предоставляем tls-ключ, как дополнительный слой защиты. Опция "0" (directionality) — говорит о направлении, на другой стороне (клиенте) надо указывать другое направление "1";
  • cipher DES-EDE3-CBC — используемый тип шифрования пакетов;
  • server 192.168.50.0 255.255.255.0 — выделяем IP-адреса с диапазоном "192.168.50.1-192.168.50.255", причем адрес "192.168.50.1" займет сам сервер, остально для клиентов;
  • push "redirect-gateway" — при успешном подключении к серверу, клиенту будет установлен новый default-gateway от vpn-сервера (см. netstat -r после соединения), таким образом весь трафик пойдет через vpn-сервер;
  • ifconfig-pool-persist ipp.txt — файл, в котором будут храниться связи "профиль клиента, выделенный ip-адрес", и после переподключения будет выдан снова прежний адрес;
  • keepalive 10 120 — устанаваливаем количество секунд для ping и ping-restart соответвенно (Нужно для поддержания подключенного состояния между соединениями к vpn-серверу);
  • comp-lzo — включаем LZO-компрессию трафика;
  • user nobody — понижаем пользовательские привелегии vpn-сервера;
  • group nogroup — понижаем пользовательские привелегии vpn-сервера;
  • persist-key — при получении сигнала SIGUSR1 или срабатывания ping-restart не нужно перечитывать сертификаты, так как у сервера не хватит привелегий (См. предыдущий пункт, "nobody:nogroup") на эти действия;
  • persist-tun — при получении сигнала SIGUSR1 или срабатывания ping-restart не нужно пересоздавать tun/tap устройства;
  • status /var/log/openvpn/openvpn-status.log — путь до status-лога;
  • log-append /var/log/openvpn/openvpn.log — путь до лога vpn-сервера;
  • verb 4 — уровень вербойса логов, от 0 до 11, детализация по нарастающей:

  • — только фатальные ошибки;
  • 1 — загрузочная информация, информация о соединении, сетевые ошибки;
  • 2,3 — TLS данные и маршрутная информация;
  • 4 — показывает параметры;
  • 5 — показывает ‘RrWw’ символы в консоли для каждого пакета, отправленные и принятые по TCP/UDP (caps) или tun/tab (lc);
  • 6-11 — отладочная информация повышающая детализацию лога;
Читайте также:  Склеить несколько пдф в один

  • mute 20 — ограничиваем количество однотипных логов;
  • client-to-client — разрешаем клиентам видеть друг-друга в сети;
  • client-config-dir ccd — каталог с кастомными настройками для клиента (создайте файл "ccd/ " для того чтобы указывать кастомные настройки для профиля someclient);
  • route 192.168.50.0 255.255.255.0 — добавляем роуты в таблицу роутов сервера, для клиентов надо использовать iroute 192.168.50.0 255.255.255.0, либо пушать роуты:
  • Для того чтобы разобраться с параметрами, я читал OpenVPN: Server configuration file и man openvpn.

    Создаем каталог для логов:

    Дальше ищем каталог "easy-rsa":

    В новых версиях easy-rsa надо устанавливать отдельно: после чего надо перейти в каталог "/usr/share/easy-rsa/".

    Теперь необходимо создать ssl-сертификаты и ключи. Для этого перейдем в каталог easy-rsa, активируем окружение vars и выполним необходимые команды:

    Вы можете предварительно отредактировать файл vars, указав необходимые настройки, например "код страны", "город", "название организации", "email" и т.д. Чтобы не указывать их каждый раз при генерации сертификата.

    Далее, скопируем сгенерированные ключи в /etc/openvpn:

    Запускаем OpenVPN:

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

    Теперь, необходимо настроить на сервере доступ в интернет подключившимся по OpenVPN клиентам. Допустим, что IP-адрес внешнего интерфейса "203.0.113.42" (вы можете узнать какой у вас в ifconfig) и так как у нас Debian, то создадим правила в iptables:

    Если вы впервые используете iptables, то создайте файл "/etc/iptables.rules" и выгрузите туда инструкции приведенные выше:

    После чего, добавьте в автозагрузку:

    И при загрузке ОС будут активироваться ваши правила в /etc/iptables.rules

    Если быть точнее, то надо в секцию вашего интерфейса добавить pre-up, но так как чаще всего именно в конце файла определён нужный интерфейс, то рекомендация выше будет верна. Развернутый пример:

    Включаем форвардинг в ядре, в файле /etc/sysctl.conf раскомментируем строчку:

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

    На стороне сервера все настроили, теперь настроим клиента и уже можно будет пользоваться!

    Генерация ключей для клиента

    Эти действия производятся на сервере! Теперь необходимо сгенерировать сертификаты для каждого клиента, которому потребуется доступ к подключению к серверу OpenVPN:

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

    Использование

    Переключаемся на клиентский компьютер (в моём случае это Xubuntu) и копируем ключи с сервера:

    Создаем файл /etc/openvpn/someserver.conf:

    А теперь поясню параметры:

    • client — говорим что мы подключаемся как клиент;
    • remote 203.0.113.42 — указываем адрес vpn-сервера;
    • redirect-gateway def1 — режим, который разрешает смену default-gateway, а после остановки vpn-соединения возвращает gateway вашего провайдера;
    • port 1194 — указываем порт vpn-сервера;
    • dev tun — указываем такое же устройство, как и у vpn-сервера;
    • proto udp — используем UDP, так как vpn-сервер тоже на UDP;
    • resolv-retry infinite — ресолвим vpn-сервер до бесконечности, полезно после потери соединения и подключения снова (например после suspend в ноутбуках);
    • nobind — не создаем постоянный порт для подключения клиента;
    • pull — разрешаем клиенту получать от vpn-сервера push-инструкции и применять их у себя (например, изменение таблицы роутов);
    • user nobody — понижаем пользовательские привелегии;
    • group nogroup — понижаем пользовательские привелегии;
    • persist-key — при получении сигнала SIGUSR1 или срабатывания ping-restart не нужно перечитывать сертификаты, так как у клиента не хватит привелегий (См. предыдущий пункт, "nobody:nogroup") на эти действия;
    • persist-tun — при получении сигнала SIGUSR1 или срабатывания ping-restart не нужно пересоздавать tun/tap устройства;
    • ca /etc/openvpn/someserver/ca.crt — путь до сгенерированного нами файла корневого сертификата;
    • cert /etc/openvpn/someserver/someclient.crt — путь до сгенерированного нами файла сертификата клиента;
    • key /etc/openvpn/someserver/someclient.key — путь до сгенерированного нами файла приватного ключа клиента;
    • tls-client — включаем TLS и во время handshake представиться клиентом;
    • tls-auth /etc/openvpn/someserver/ta.key 1 — предоставляем tls-ключ, как дополнительный слой защиты;
    • cipher DES-EDE3-CBC — используемый тип шифрования пакетов (должен совдадать с серверным);
    • comp-lzo — включаем LZO-компрессию трафика;
    • verb 3 — уровень вербойса логов, от 0 до 11. Подробнее описывал в такой же секции конфига сервера;
    • mute 20 — ограничиваем количество однотипных логов;
    • log openvpn.log — путь до лога клиента.

    Для того чтобы разобраться с параметрами, я читал OpenVPN: Client configuration file и man openvpn.

    Запускаемся

    Можно запустить все указанные в AUTOSTART (смотрите /etc/default/openvpn) подключения:

    Или запустить конкретное подключение так:

    Проверить подключение можно так:

    Если видим подключения с интерфейсом "tun0", то всё впорядке.

    Проверим работает ли интернет через наш OpenVPN-сервер, для этого зайдите на сайт http://www.geoiptool.com/ и убедитесь, там ли ваш сервер находится географически? Если да, то всё окей, иначе смотрите логи на клиенте /etc/openvpn/openvpn.log и пишите комментарии.

    Отключаем автоматическое поднятие соединения на клиенте

    Я пользуюсь Xubuntu, и отключаю автостарт всех OpenVPN-профайлов так:

    Находим AUTOSTART="none" и расскоментируем. Также там будут примеры как указать нужный профиль, например можно указать созданный нами профиль AUTOSTART="someserver".

    Ссылка на основную публикацию
    Logitech deluxe 250 keyboard драйвер
    Ниже показаны совместимые с ОС Windows 7 драйвера для Logitech Deluxe 250 USB Keyboard. Каждый драйвер клавиатуры Logitech Deluxe 250...
    Adblock detector