Первое, что приходит в голову при упоминании VPN, - это анонимность и защищенность передаваемых данных. Так ли это на самом деле? Давай разберемся.

Когда необходимо получить доступ к корпоративной сети, безопасно передать важную информацию по открытым каналам связи, скрыть свой трафик от бдительного взора провайдера, скрыть свое реальное местоположение при проведении каких-либо не совсем законных (или совсем не законных) действий, обычно прибегают к использованию VPN. Но стоит ли слепо полагаться на VPN, ставя на кон безопасность своих данных и собственную безопасность? Однозначно - нет. Почему? Давай разбираться.

WARNING

Вся информация предоставлена исключительно в ознакомительных целях. Ни редакция, ни автор не несут ответственности за любой возможный вред, причиненный материалами данной статьи.

VPN нам нужен!

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

Утечка VPN-трафика

Первая проблема, связанная с виртуальными частными сетями, - это утечка трафика. То есть тот трафик, который должен быть передан через VPN-соединение в зашифрованном виде, попадает в сеть в открытом виде. Данный сценарий не является следствием ошибки в VPN-сервере или клиенте. Здесь все гораздо интереснее. Самый простой вариант - внезапный разрыв VPN-соединения. Ты решил просканировать хост или подсеть с помощью Nmap, запустил сканер, отошел на несколько минут от монитора, и тут VPN-соединение внезапно отвалилось. Но сканер при этом продолжает работать. И сканирование идет уже с твоего адреса. Вот такая неприятная ситуация. Но есть сценарии и интересней. Например, утечка VPN-трафика широко распространена в сетях (на хостах), поддерживающих обе версии протокола IP (так называемые dual-stacked сети/хосты).

Корень зла

Сосуществование двух протоколов - IPv4 и IPv6 - имеет множество интересных и тонких аспектов, которые могут приводить к неожиданным последствиям. Несмотря на то что шестая версия протокола IP не имеет обратной совместимости с четвертой версией, обе эти версии как бы «склеены» вместе системой доменных имен (DNS). Чтобы было понятней, о чем идет речь, давай рассмотрим простенький пример. Например, возьмем сайт (скажем, www.example.com), который имеет поддержку IPv4 и IPv6. Соответствующее ему доменное имя (www.example.com в нашем случае) будет содержать DNS-записи обоих типов: А и АААА. Каждая А-запись содержит один IPv4-адрес, а каждая АААА-запись содержит один IPv6-адрес. Причем для одного доменного имени может быть по несколько записей обоих типов. Таким образом, когда приложение, поддерживающее оба протокола, захочет взаимодействовать с сайтом, оно может запросить любой из доступных адресов. Предпочитаемое семейство адресов (IPv4 или IPv6) и конечный адрес, который будет использоваться приложением (учитывая, что их существует несколько для четвертой и шестой версий), будет отличаться от одной реализации протокола к другой.

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

VPN и двойной стек протоколов

Многие реализации VPN не поддерживают или, что еще хуже, полностью игнорируют протокол IPv6. При установке соединения программное обеспечение VPN берет на себя заботу по транспортировке IPv4-трафика - добавляет дефолтный маршрут для IPv4-пакетов, обеспечивая тем самым, чтобы весь IPv4-трафик отправлялся через VPN-соединение (вместо того чтобы он отправлялся в открытом виде через локальный роутер). Однако, если IPv6 не поддерживается (или полностью игнорируется), каждый пакет, в заголовке которого указан IPv6-адрес получателя, будет отправлен в открытом виде через локальный IPv6-роутер.

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

Легитимный сценарий утечки VPN-трафика

Рассмотрим хост, который поддерживает оба стека протоколов, использует VPN-клиент (работающий только с IPv4-трафиком) для подключения к VPN-серверу и подключен к dual-stacked сети. Если какому-то приложению на хосте нужно взаимодействовать с dual-stacked узлом, клиент обычно запрашивает и А-, и АААА-DNS-записи. Так как хост поддерживает оба протокола, а удаленный узел будет иметь оба типа DNS-записей (А и АААА), то одним из вероятных вариантов развития событий будет использование для связи между ними IPv6-протокола. А так как VPN-клиент не поддерживает шестую версию протокола, то IPv6-трафик не будет отправляться через VPN-соединение, а будет отправляться в открытом виде через локальную сеть.

Такой вариант развития событий подвергает угрозе передаваемые в открытом виде ценные данные, в то время как мы думаем, что они безопасно передаются через VPN-соединение. В данном конкретном случае утечка VPN-трафика является побочным эффектом использования ПО, не поддерживающего IPv6, в сети (и на хосте), поддерживающей(ем) оба протокола.

Преднамеренно вызываем утечку VPN-трафика

Атакующий может преднамеренно вызвать подключение по протоколу IPv6 на компьютере жертвы, посылая поддельные ICMPv6 Router Advertisement сообщения. Подобные пакеты можно рассылать при помощи таких утилит, как rtadvd , SI6 Networks" IPv6 Toolkit или THC-IPv6 . Как только соединение по протоколу IPv6 установлено, «общение» с системой, поддерживающей оба стека протоколов, может вылиться, как рассмотрено выше, в утечку VPN-трафика.

И хотя данная атака может быть достаточно плодотворной (из-за растущего числа сайтов, поддерживающих IPv6), она приведет к утечке трафика, только когда получатель поддерживает обе версии протокола IP. Однако для злоумышленника не составит труда вызвать утечки трафика и для любого получателя (dual-stacked или нет). Рассылая поддельные Router Advertisement сообщения, содержащие соответствующую RDNSS-опцию, атакующий может прикинуться локальным рекурсивным DNS-сервером, затем провести DNS-спуфинг, чтобы осуществить атаку man-in-the-middle и перехватить соответствующий трафик. Как и в предыдущем случае, такие инструменты, как SI6-Toolkit и THC-IPv6, могут легко провернуть такой трюк.

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

1. Если VPN-клиент сконфигурирован таким образом, чтобы отправлять весь IPv4-трафик через VPN-соединение, то:

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

1. Чтобы избежать утечки трафика, в случае если VPN-соединение внезапно отвалится и все пакеты будут отправляться через default gateway, можно:
2. принудительно заставить весь трафик идти через VPN route delete 0.0.0.0 192.168.1.1 // удаляем default gateway route add 83.170.76.128 mask 255.255.255.255 192.168.1.1 metric 1

• воспользоваться утилитой VPNetMon , которая отслеживает состояние VPN-соединения и, как только оно пропадает, мгновенно завершает указанные пользователем приложения (например, торрент-клиенты, веб-браузеры, сканеры);
• или утилитой VPNCheck , которая в зависимости от выбора пользователя может либо полностью отключить сетевую карту, либо просто завершить указанные приложения.

1. Проверить, уязвима ли твоя машина к утечке DNS-трафика, можно на сайте , после чего применить советы, как пофиксить утечку, описанные .

Расшифровка VPN-трафика

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

Ахиллесова пята

При VPN-соединениях на базе протокола PPTP (Point-to-Point Tunneling Protocol) аутентификация пользователей проводится по протоколу MS-CHAPv2, разработанному компанией Microsoft. Несмотря на то что MS-CHAPv2 устарел и очень часто становится предметом критики, его продолжают активно использовать. Чтобы окончательно отправить его на свалку истории, за дело взялся известный исследователь Мокси Марлинспайк, который на двадцатой конференции DEF CON отчитался, что поставленная цель достигнута - протокол взломан. Надо сказать, что безопасностью этого протокола озадачивались и ранее, но столь долгое использование MS-CHAPv2, возможно, связано с тем, что многие исследователи концентрировались только на его уязвимости к атакам по словарю. Ограниченность исследований и широкое число поддерживаемых клиентов, встроенная поддержка операционными системами - все это обеспечило протоколу MS-CHAPv2 широкое распространение. Для нас же проблема кроется в том, что MS-CHAPv2 применяется в протоколе PPTP, который используется многими VPN-сервисами (например, такими крупными, как анонимный VPN-сервис IPredator и The Pirate Bay’s VPN).

Если обратиться к истории, то уже в 1999 году в своем исследовании протокола PPTP Брюс Шнайер указал, что «Microsoft улучшил PPTP, исправив основные изъяны безопасности. Однако фундаментальная слабость аутентификации и шифрования протокола в том, что он безопасен настолько, насколько безопасен выбранный пользователем пароль». Это почему-то заставило провайдеров поверить, что ничего страшного в PPTP нет и если требовать от пользователя придумывать сложные пароли, то передаваемые данные будут в безопасности. Сервис Riseup.net настолько проникся этой идеей, что решил самостоятельно генерировать для пользователей пароли длиной в 21 символ, не давая им возможности установить свои. Но даже такая жесткая мера не спасает от расшифровки трафика. Чтобы понять почему, давай поближе познакомимся с протоколом MS-CHAPv2 и посмотрим, как же Мокси Марлинспайк сумел его взломать.

Протокол MS-CHAPv2

Как уже было сказано, MSCHAPv2 применяется для аутентификации пользователей. Происходит она в несколько этапов:

• клиент посылает запрос на аутентификацию серверу, открыто передавая свой login;
• сервер возвращает клиенту 16-байтовый случайный отклик (Authenticator Challenge);
• клиент генерирует 16-байтовый PAC (Peer Authenticator Challenge - равный отклик аутентификации);
• клиент объединяет PAC, отклик сервера и свое user name в одну строку;
• с полученной строки снимается 8-байтовый хеш по алгоритму SHA-1 и посылается серверу;
• сервер извлекает из своей базы хеш данного клиента и расшифровывает его ответ;
• если результат расшифровки совпадет с исходным откликом, все ОK, и наоборот;
• впоследствии сервер берет PAC клиента и на основе хеша генерирует 20-байтовый AR (Authenticator Response - аутентификационный ответ), передавая его клиенту;
• клиент проделывает ту же самую операцию и сравнивает полученный AR с ответом сервера;
• если все совпадает, клиент аутентифицируется сервером. На рисунке представлена наглядная схема работы протокола.

На первый взгляд протокол кажется излишне сложным - куча хешей, шифрование, случайные challenge. На самом деле все не так уж и сложно. Если присмотреться внимательней, то можно заметить, что во всем протоколе остается неизвестной только одна вещь - MD4-хеш пароля пользователя, на основании которого строятся три DES-ключа. Остальные же параметры либо передаются в открытом виде, либо могут быть получены из того, что передается в открытом виде.

Так как почти все параметры известны, то мы можем их не рассматривать, а остановить свое пристальное внимание на том, что неизвестно, и выяснить, что это нам дает.

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

Имея на руках перехваченный трафик, можно попробовать его расшифровать. Есть несколько инструментов (например, asleap), которые позволяют подобрать пароль пользователя через атаку по словарю. Недостаток этих инструментов в том, что они не дают стопроцентной гарантии результата, а успех напрямую зависит от выбранного словаря. Подбирать же пароль простым брутфорсом тоже не очень эффективно - например, в случае с PPTP VPN сервисом riseup.net, который принудительно устанавливает пароли длиной в 21 символ, придется перебирать 96 вариантов символа для каждого из 21 символов. Это в результате дает 96^21 вариантов, что чуть больше, чем 2^138. Иными словами, надо подобрать 138-битный ключ. В ситуации же, когда длина пароля неизвестна, имеет смысл подбирать MD4-хеш пароля. Учитывая, что его длина равна 128 бит, получаем 2^128 вариантов - на данный момент это просто нереально вычислить.

Разделяй и властвуй

MD4-хеш пароля используется в качестве входных данных для трех DES-операций. DES-ключи имеют длину 7 байт, так что каждая DES-операция использует 7-байтовый фрагмент MD4-хеша. Все это оставляет возможность для классической атаки divide and conquer. Вместо того чтобы полностью брутить MD4-хеш (а это, как ты помнишь, 2^128 вариантов), мы можем подбирать его по частям в 7 байт. Так как используются три DES-операции и каждая DES-операция абсолютно независима от других, это дает общую сложность подбора, равную 2^56 + 2^56 + 2^56, или 2^57.59. Это уже значительно лучше, чем 2^138 и 2^128, но все еще слишком большое число вариантов. Хотя, как ты мог заметить, в эти вычисления закралась ошибка. В алгоритме используются три DES-ключа, каждый размером в 7 байт, то есть всего 21 байт. Эти ключи берутся из MD4-хеша пароля, длина которого всего 16 байт.

То есть не хватает 5 байт для построения третьего DES-ключа. В Microsoft решили эту задачу просто, тупо заполнив недостающие байты нулями и фактически сведя эффективность третьего ключа к двум байтам.

Так как третий ключ имеет эффективную длину всего лишь два байта, то есть 2^16 вариантов, его подбор занимает считаные секунды, доказывая эффективность атаки divide and conquer. Итак, можно считать, что последние два байта хеша известны, остается подобрать оставшиеся 14. Также разделив их на две части по 7 байт, имеем общее число вариантов для перебора, равное 2^56 + 2^56 = 2^57. Все еще слишком много, но уже значительно лучше. Обрати внимание, что оставшиеся DES-операции шифруют один и тот же текст, только при помощи разных ключей. Можно записать алгоритм перебора следующим образом:

Но так как текст шифруется один и тот же, то правильнее сделать вот так:

То есть получается 2^56 вариантов ключей для перебора. А это значит, что безопасность MS-CHAPv2 может быть сведена к стойкости одного DES-шифрования.

Взлом DES

Теперь, когда диапазон подбора ключа известен, для успешного завершения атаки дело остается только за вычислительными мощностями. В 1998 году Electronic Frontier Foundation построила машину Deep Crack, которая стоила 250 тысяч долларов и позволяла взламывать DES-ключ в среднем за четыре с половиной дня. В настоящее время Pico Computing, специализирующаяся на построении FPGA-оборудования для криптографических приложений, построила FPGA-устройство (DES cracking box), которое реализует DES как конвейер с одной DES-операцией на каждый тактовый цикл. Обладая 40 ядрами по 450 МГц, оно позволяет перебирать 18 миллиардов ключей в секунду. Обладая такой скоростью перебора, DES cracking box в худшем случае взламывает ключ DES за 23 часа, а в среднем за полдня. Данная чудо-машина доступна через коммерческий веб-сервис loudcracker.com . Так что теперь можно взломать любой MS-CHAPv2 handshake меньше, чем за день. А имея на руках хеш пароля, можно аутентифицироваться от имени этого пользователя на VPN-сервисе или просто расшифровывать его трафик.

Для автоматизации работы с сервисом и обработки перехваченного трафика Мокси выложил в открытый доступ утилиту chapcrack. Она парсит перехваченный сетевой трафик, ища MS-CHAPv2 handshake’и. Для каждого найденного «рукопожатия» она выводит имя пользователя, известный открытый текст, два известных шифртекста и взламывает третий DES-ключ. Кроме этого, она генерирует токен для CloudCracker, в котором закодированы три параметра, необходимые, чтобы сервис взломал оставшиеся ключи.

CloudCracker & Chapcrack

На случай, если тебе понадобится взломать DES-ключи из перехваченного пользовательского трафика, приведу небольшую пошаговую инструкцию.

1. Скачиваем библиотеку Passlib , реализующую более 30 различных алгоритмов хеширования для языка Python, распаковываем и устанавливаем: python setup.py install
2. Устанавливаем python-m2crypto - обертку OpenSSL для Python: sudo apt-get install python-m2crypto
3. Скачиваем саму утилиту chapcrack , распаковываем и устанавливаем: python setup.py install
4. Chapcrack установлена, можно приступать к парсингу перехваченного трафика. Утилита принимает на вход cap-файл, ищет в нем MS-CHAPv2 handshake’и, из которых извлекает необходимую для взлома информацию. chapcrack parse -i tests/pptp
5. Из выводимых утилитой chapcrack данных копируем значение строки CloudCracker Submission и сохраняем в файл (например, output.txt)
6. Идем на cloudcracker.com, на панели «Start Cracking» выбираем File Type, равный «MS-CHAPv2 (PPTP/WPA-E)», выбираем предварительно подготовленный на предыдущем шаге файл output.txt, нажимаем Next -> Next и указываем свой e-mail, на который придет сообщение по окончании взлома.

К небольшому сожалению, сервис CloudCracker платный. К счастью, за взлом ключиков придется отдать не так уж много - всего 20 баксов.

Что делать?

Хоть Microsoft и пишет на своем сайте, что на данный момент не располагает сведениями об активных атаках с использованием chapcrack, а также о последствиях таких атак для пользовательских систем, но это еще не значит, что все в порядке. Мокси рекомендует всем пользователям и провайдерам PPTP VPN решений начинать миграцию на другой VPN-протокол. А PPTP-трафик считать незашифрованным. Как видишь, налицо еще одна ситуация, когда VPN может нас серьезно подвести.

Заключение

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

Расскажите побольше про VPN безопасность, как можно защититься от утечки VPN-трафика?

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

Но одним правильным выбором ВПН проблема не решается. Есть такая неприятная вещь — как утечка VPN-трафика. Сегодня я расскажу про то, как попытаться предотвратить утечку ВПН-трафика на Windows и Linux. Я расскажу о пяти способах, с помощью которых вы сможете сделать использование VPN более безопасным. Конечно же они не решат всех проблем утечки VPN-трафика, но кардинально улучшат VPN безопасность.

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

• Предисловие
• Утечка VPN-трафика
• Защита от утечки VPN-трафика
• VPN безопасность с помощью VPN Kill Switch

Подробно о технологии VPN вы можете узнать в статье « ».

Утечка VPN-трафика

Что это такое?

Это когда трафик, который должен идти через VPN-соединение, попадает в сеть в обычном открытом виде. Как правило это происходит не из-за проблем ВПН-сервера или клиента. Существует две причины утечки в виртуальных частных сетях:

1. Внезапная потеря VPN-соединения. Представим ситуацию, в которой вы через ВПН запустили какой-то процесс, и вдруг ночью, когда вы крепко спите, происходит разрыв соединения. Что в такой ситуации произойдет вы уже знаете.
2. Причиной утечки зашифрованного трафика может быть и распространенная проблема на хостах поддерживающих две версии протокола IP (так называемые dual-stacked сети/хосты).

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

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

Защита от утечки VPN-трафика

Для Windows существует несколько способов: с помощью планировщика задач, bat-файла и с помощью специальных утилит. Давайте по порядку.

Безопасность VPN с помощью планировщика задач

Комбинацией клавиш Win + R запускаем окно выполнить.

Командой «taskschd.msc» запускаем планировщик задач.

В выпадающем меню «Действие» выбираем пункт «Создать задачу».

На вкладке «Общее» в поле «Имя» вводим названия действия.

Отмечаем галочкой поле «Выполнить с наивысшими правами».

Переходим на вкладку «Триггеры» и нажимаем на кнопку «Создать».

В окне создания триггера в выпадающем меню «Начать задачу» выбираем пункт «При событии».

В выпадающем меню «Журнал» пункт «Приложение».

В выпадающем меню «Источник» пункт «RasClient».

В выпадающем меню «Код события» вводим код события «20226».

Переходим на вкладку «Действия» и нажимаем на кнопку «Создать». В окне «Создание действия» в выпадающем меню «Действие» выбираем пункт «Запуск программы».

В поле «Программа и сценарий» вводим «taskkill.exe».

В поле «Добавить аргументы» вводим «/f /im spysoftnet.exe». Где вместо spysoftnet.exe вводим имя нужного исполняемого файла программы. Например utorrent.exe.

Еще одним вариантом может быть использование PowerShell. Этот вариант предлагает не убивать каждый отдельный процесс с помощью «taskkill.exe», а отключать всю сеть в случае неполадки VPN-соединения. Делается это так.

В место «taskkill.exe» в поле «Программа и сценарий» вводим «powershell.exe».

Вместо аргумента «/f /im spysoftnet.exe» вводим аргумент «Get-NetAdapter | Disable-NetAdapter -Confirm:$false».

После такого отключения вернуть сеть в прежнее состояния можно только ручками, с помощью команды «powershell.exe Get-NetAdapter | Enable-NetAdapter -Confirm:$false».

Если вы пользуетесь VPN на ноутбуке, то было бы правильнее в поле «Питание» на вкладке «Условия» убрать галочку с пункта «Запускать только при питании от электросети».

С этим способом мы разобрались. Давайте посмотрим что еще можно сделать, чтоб защитится от утечки VPN-трафика.

Безопасность VPN с помощью VPN Kill Switch

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

Все что от вас требуется — это после запуска VPN запустить bat-файл и выбрать пункт «1 — Enable Kill Switch (Включение Kill Switch)».

Теперь в случае потери VPN-соединения скрипт автоматический удалит IP-адрес Default Gateway в вашей сетевой карте, сделав доступ к сети недоступным для всех установленных на компьютере программ.

Для восстановления прежних настроек сети необходимо повторно запустить файл и выбрать пункт «2- Disable Kill Swith (Отключение Kill Switch)».

Утилиты для защиты от утечки VPN-трафика

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

VPN безопасность с VPN Watcher

VPN Watcher — это небольшая утилита для контроля VPN-соединения. Добавляем необходимую программу зеленой кнопкой. Включаем режим мониторинга и спим спокойно.

Программа распространяется в двух версиях: платная и бесплатная. В бесплатной версии пользователь может добавить только одну программу. Софт работает на операционных систем Windows и MAC OS X.

Большим достоинством этой утилиты является низкая потребление ресурсов памяти и процессора. Всего 2 мб.

VPN безопасность с VPNCheck

VPNCheck — это навороченный инструмент для контроля и управления VPN соединением. У программы две версии: платная, которая имеет более богатый функционал. Работает с OpenVPN имеет инструмент исправляющий утечку DNS и еще многое чего. Также в платной версии вы можете добавить любое количество программ.

Главное окно VPNCheck

В бесплатной версии VPNCheck умеет мониторить PPTP VPN. Автоматический закрывает все программы при разрыве VPN. Имеет ограничение в три программы.

Настройка VPNCheck не сложная. Для начала запустите программу. После чего нажмите на кнопку «Config» и добавьте программу которую хотите контролировать.

Необходимо отметить по вашему усмотрению чекбоксы «Close» — закрытые программы и «Autorun» — повторный запуск программы.

Настройка VPNCheck

Также необходимо заполнить поле «Login info». Все данные должны быть идентичны с настройками VPN в операционной системе.

Бесплатная версия доступна для Windows и Linux. Платная только для Windows.

VPN безопасность с VPN Lifeguard

VPN Lifeguard — это бесплатная, опенсорсная, портабельная утилита, которая запрещает работу программам во время потери VPN соединения. Программа по функционалу очень похожа на VPN Watcher. При правильной настройке отлично справляется со своей задачей и прекрасно работает.

Содержание

Virtual Private Network – это виртуальная частная сеть, которая используются для обеспечения защищенного подключения внутри корпоративных соединений и доступа в интернет. Главный плюс ВПН – высокая безопасность за счет шифрования внутреннего трафика, что важно при передаче данных.

Что такое VPN-подключение

Многие люди, когда сталкиваются с этой аббревиатурой, спрашивают: VPN – что это и зачем нужно? Данная технология открывает возможность создать сетевое соединение поверх другого. Работает ВПН в нескольких режимах:

• узел-сеть;
• сеть-сеть;
• узел-узел.

Организация частной виртуальной сети на сетевых уровнях позволяет использовать TCP и UDP протоколы. Все данные, которые проходят через компьютеры, шифруются. Это дополнительная защита для вашего подключения. Есть множество примеров, которые объясняют, что такое VPN-соединение и зачем его нужно использовать. Ниже будет подробно освещен данный вопрос.

Зачем нужен VPN

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

1. ВПН-сервис используется для отправки конфиденциальных данных компании между филиалами. Это помогает защитить важную информацию от перехвата.
2. Если вам необходимо обойти привязку сервиса по географической местности. К примеру, сервис «Яндекс Музыка» доступен только жителям России и жителям бывших стран СНГ. Если вы русскоязычный житель США, то послушать записи у вас не получится. VPN-сервис поможет обойти этот запрет, подменяя адрес сети на российский.
3. Скрыть от провайдера посещение сайтов. Не каждый человек готов делиться своей деятельностью в интернете, поэтому будет защищать свои посещения при помощи ВПН.

Как работает VPN

Когда вы задействуете другой VPN-канал, ваш IP будет принадлежать стране, где находится данная защищенная сеть. При подключении будет создан туннель между ВПН-сервером и вашим компьютером. После этого в логах (записях) провайдера будет набор непонятных символов. Анализ данных специальной программой не даст результатов. Если не использовать эту технологию, то проток HTTP сразу же укажет, к какому сайту вы подключаетесь.

Структура VPN

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

Когда программа для VPN подключает удаленного пользователя, сервер требует прохождения двух важных процессов: сначала идентификации, затем – аутентификации. Это необходимо для получения прав пользоваться данным соединением. Если вы полностью прошли успешно эти два этапа, ваша сеть наделяется полномочиями, которые открывают возможность работы. По сути – это процесс авторизации.

Классификация VPN

Есть несколько видов виртуальных частных сетей. Существуют варианты по степени защищенности, способу реализации, уровню работы по модели ISO/OSI, задействованному протоколу. Можно использовать платный доступ или бесплатный VPN-сервис от Google. Исходя из степени защищенности, каналы могут быть «защищенными» или «доверительными». Последние нужны, если само по себе соединение обладает нужным уровнем защиты. Для организации первого варианта следует использовать следующие технологии:

• PPTP;
• OpenVPN;
• IPSec.

Как создать VPN-сервер

Для всех пользователей компьютера есть способ, как подключить VPN самостоятельно. Ниже будет рассмотрен вариант на операционной системе Виндовс. Эта инструкция не предусматривает использование дополнительного ПО. Настройка проводится следующим образом:

1. Чтобы сделать новое подключение, необходимо открыть панель просмотра сетевых доступов. Начните вбивать в поиске слова «Сетевых подключений».
2. Нажмите на кнопку «Alt», в меню нажмите на раздел «Файл» и выберите пункт «Новое входящее подключение».
3. Затем выставите пользователя, которому будет предоставлено соединение с этим компьютером через VPN (если у вас только одна учетная запись на ПК, то нужно создать обязательно пароль для нее). Установите птичку и нажмите «Далее».
4. Далее будет предложено выбрать тип подключения, можно оставить галочку напротив «Интернет».
5. Следующим шагом станет включение сетевых протоколов, которые на данном ВПН будут работать. Выставите галочки на всех пунктах, кроме второго. При желании можно установить конкретный IP, шлюзы DNS и порты в протоколе IPv4, но легче оставить автоматическое назначение.
6. Когда кликните по кнопке «Разрешить доступ», операционка самостоятельно создаст сервер, отобразит окно с именем компьютера. Оно понадобится для соединения.
7. На этом создание домашнего VPN-сервера завершено.

Как настроить VPN на Андроиде

Выше был описан способ, как создать VPN-подключение на персональном компьютере. Однако многие уже давно выполняют все действия при помощи телефона. Если не знаете, что такое VPN на Андроид, то все вышеописанные факты о данном типе подключения справедливы и для смартфона. Конфигурация современных аппаратов обеспечивает комфортное пользование интернетом на высокой скорости. В некоторых случаях (для запуска игр, открытия сайтов) используют подмену прокси или анонимайзеры, но для стабильного и быстрого подключения VPN подходит лучше.

Если вам уже ясно, что такое VPN в телефон, то можно перейти непосредственно к созданию туннеля. Выполнить это можно на любом устройстве с поддержкой Андроид. Производится подключение следующим образом:

1. Зайдите в раздел с настройками, нажмите на раздел «Сеть».
2. Найдите пункт под названием «Дополнительные настройки» и перейдите на раздел «VPN». Далее нужен будет пин-код или пароль, который разблокирует возможность создания сети.
3. Следующий шаг – добавление VPN-соединения. Укажите название в поле «Server», имя в поле «username», установите тип подключения. Тапните по кнопке «Сохранить».
4. После этого в списке появится новое подключение, которое можете использовать для смены своего стандартного соединения.
5. На экране появится значок, который будет указывать на наличие подключения. Если по нему тапнуть, вам будет предоставлена статистика полученных/переданных данных. Здесь же можно отключить соединение VPN.

Видео: бесплатный VPN-сервис

Нашли в тексте ошибку? Выделите её, нажмите Ctrl + Enter и мы всё исправим!

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

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

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

Виртуальная частная сеть Virtual Private Network (VPN) - это технологии, предоставляющие возможность обеспечивать одно или же сразу несколько сетевых соединений поверх другой сети, например, Интернета.

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

Виды VPN подключений

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

Виртуальная частная сеть РРТР

РРТР - Point-toPoint Tunneling Protocol -туннельный протокол типа «точка-точка», который поможет установить защищенный туннель в незащищенной сети. Он является наиболее популярным способом VPN-подключения, однако многие интернет-провайдеры блокируют работу таких приложений.

Виртуальная частная сеть OpenVPN

OpenVPN - представляет собой свободную реализацию данной технологии с предоставлением открытого кода для создания своих зашифрованных каналов по типам «точка-точка» или «сервер-клиент». Последний позволяет использовать в качестве VPN-сервера другой компьютер. Однако для настройки туннеля требуется установка специального программного обеспечения вкупе со знаниями для работы с ним.

Виртуальная частная сеть L2TP

L2TP (Layer 2 Tunneling Protocol) - наиболее трудоемкий для настройки вид VPN-туннеля, но позволяющий создавать его с заданными приоритетами доступа, делая наиболее защищенным.

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

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

Сделаем три ремарки:
Во-первых, интерфейсы Loopback и адреса с маской /32 мы выбрали просто для теста, фактически это вполне бы могли быть интерфейсы fa1/0.15 и fa0/1.16 с подсетями 172.16.15.0/24 и 172.16.16.0/24, например, или любые другие.
Во-вторых, мы тут всё ведём речи о публичных сетях и адресах, но на самом деле, конечно, это не имеет значения и туннели вполне можно поднимать даже внутри своей корпоративной сети, когда конечные сети и так имеют IP-связность без туннеля.
В-третьих, несмотря на то, что теоретически обратно трафик может возвращаться и не по туннелю, создать его необходимо, чтобы конечный узел могу успешно декапсулировать GRE-пакеты

Обычный GRE – яркий пример туннелирования, который очень просто настраивается и сравнительно легко траблшутится.
Очевидно, вы уже догадываетесь, какие три большие проблемы подстерегают нас на этом поле?

• Безопасность. Данные, инкапсулированные в GRE, передаются тем не менее в открытом виде.
• Сложность масштабирования. Если у вас 5-7 филиалов, обслуживание такого количества туннелей ещё кажется возможным, а если их 50? Причём туннелирование трафика зачастую производится на CPU, особенно на младшей и средней линейках, поэтому это лишняя нагрузка на процессор.
• Все филиалы будут взаимодействовать друг с другом через центральный узел, хотя могли бы напрямую.

IPSec

Первую озвученную выше проблему призвано решить шифрование.

Сейчас для организации шифрованного VPN-канала используются преимущественно следующие технологии: IPSec (IP Security), OpenVPN и PPTP (Point-to-Point Tunneling Protocol).

Бессменным лидером, конечно, является IPSec, о нём и поговорим.

Для начала нужно уяснить себе, что IPSec – это не протокол, это стандарт, включающий в себя целых три протокола, каждый со своими функциями:

1. ESP (Encapsulating Security Payload – безопасная инкапсуляция полезной нагрузки) занимается непосредственно шифрованием данных, а также может обеспечивать аутентификацию источника и проверку целостности данных
2. AH (Authentication Header – заголовок аутентификации) отвечает за аутентификацию источника и проверку целостности данных
3. IKE (Internet Key Exchange protocol – протокол обмена ключами) используется для формирования IPSec SA (Security Association, об этом чуть ниже), проще говоря, согласования работы участников защищенного соединения. Используя этот протокол, участники договариваются, какой алгоритм шифрования будет использоваться, по какому алгоритму будет производиться (и будет ли вообще) проверка целостности, как аутентифицировать друг друга

Прежде чем переходить дальше, разберемся с термином SA – Security Association. SA в общем смысле представляет собой набор параметров защищенного соединения (например, алгоритм шифрования, ключ шифрования), который может использоваться обеими сторонами соединения. У каждого соединения есть ассоциированный с ним SA.
Теперь по порядку, как создается защищенное соединение в IPSec:

• Для начала, участникам надо договориться, какие алгоритмы/механизмы защиты они будут использовать для своего защищенного соединения, поэтому в дело вступает IKE. Процесс состоит из двух фаз:
  • Фаза первая: участники аутентифицируют друг друга и договариваются о параметрах установки специального соединения (тоже защищенного), предназначенного только для обмена информацией о желаемых/поддерживаемых алгоритмах шифрования и прочих деталях будущего IPSec-туннеля. Параметры этого мини-туннеля (правильно он называется ISAKMP Tunnel) определяются политикой ISAKMP, в режим редактирования которой мы можем попасть из конфигурационного режима командой crypto isakmp policy номер_политики . Если стороны пришли к соглашению, устанавливается ISAKMP туннель (его наличие можно посмотреть командой show crypto isakmp sa ), по которому уже проходит вторая фаза IKE.
  • Фаза вторая: уже доверяющие друг другу участники договариваются о том, как строить основной туннель для данных. Они по очереди предлагают друг другу варианты, указанные в команде crypto ipsec transform-set , и, если приходят к согласию, поднимают основной туннель. Нужно сказать, что, после его установления, вспомогательный ISAKMP туннель никуда не пропадает – он используется для обновления SA основного. Дело в том, что ключи, выбираемые для шифрования информации в IPSec-туннеле, имеют некоторое “время жизни” (может выражаться как в количестве байт, так и в секундах – что первое достигнет порогового значения), по истечение которого должны быть заменены. Это как пароль, который вы меняете раз в час (по умолчанию lifetime IPSec SA составляет 4608000 килобайт/3600 секунд).
• Участники получили шифрованный туннель с параметрами, которые их всех устраивают, и направляют туда потоки данных, подлежащие шифрованию, т.е., подпадающие под указанный в crypto map аксесс-лист.
• Периодически, в соответствии с настроенным lifetime, обновляются ключи шифрования для основного туннеля: участники вновь связываются по ISAKMP-туннелю, проходят вторую фазу и устанавливают новые SA.

Строго говоря, в этом процессе есть нулевой шаг: некий трафик должен попасть в соответствие аксесс-листу в крипто мапе. Только после этого будет происходить все остальное.

Теперь немного о трансформ-сете и чем отличается ESP от AH. Как будут шифроваться наши данные, идущие через туннель, определяет команда crypto ipsec transform-set имя_сета , после которой идет название протокола, который будет использован (ESP или AH) + алгоритм, по которому будет работать протокол. Например, команда crypto ipsec transform-set SET1 esp-aes даст понять роутеру, что трансформ-сет с именем “SET1”, если он будет применен, будет работать только по протоколу ESP c шифрованием алгоритмом AES. Ну если с ESP все более-менее понятно, его дело-шифровать (обеспечивать конфиденциальность ), то что такое AH и зачем он вообще нужен? AH обеспечивает аутентификацию данных, то есть дает уверенность, что эти данные пришли именно от того, с кем мы установили связь, и не были изменены по дороге. Если не углубляться в подробности, работает это так: в каждый пакет между заголовком IP и заголовком транспортного уровня вставляется заголовок AH, в котором присутствует:

• информация, по которой получатель может понять, к какой SA относится данный пакет (т.е., в том числе, по какому алгоритму ему считать хеш для сравнения – MD5 или SHA)
• так называемый ICV (Integrity Check Value), представляющий собой хеш от пакета (на самом деле, не всего пакета, а неизменяемых в процессе путешествия полей), который позволяет однозначно убедиться получателю, что этот пакет не изменялся по дороге, путем вычисления хеша от той же информации и сравнения результата со значением этого поля.

IPSec может работать в двух режимах: туннельном и транспортном.

Туннельный режим работы IPSec

В этом режиме берётся ваш изначальный IP-пакет, шифруется полностью, вместе с заголовком IP, добавляется служебная информация IPSec и новый заголовок IP:

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

Это режим по умолчанию.

Давайте опять разберёмся по ходу настройки.

На локальной стороне:

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

crypto isakmp policy 1
encr aes
authentication pre-share

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

Указываем pre-shared key для проверки подлинности соседа 200.0.0.1

crypto isakmp key CISCO address 200.0.0.1

Далее мы указываем параметры для обработки трафика. Алгоритм шифрования AES с использованием ESP-заголовка и алгоритм аутентификации.

На самом деле мы указываем сразу набор протоколов, как вы видите, он и называется transform-set. При установке IPSec-сессии маршрутизаторы обмениваются этими наборами. Они должны совпадать.

Для упрощения траблшутинга имена для transform-set обычно даются по применённым протоколам.

Теперь создаём карту шифрования:

crypto map MAP1 10 ipsec-isakmp
set peer 200.0.0.1
match address 101

Вот именно тут и определяется адрес соседа IPSec, с которым потом будет устанавливаться туннель – 200.0.0.1. Тут же привязывается набор протоколов и ACL, определяющий, какой трафик будет шифроваться и передаваться через туннель.

В нашем случае он выглядит так:

access-list 101 permit ip host 10.0.0.0 host 10.1.1.0

Будьте внимательны при задании ACL. Он определяет параметры не только исходящего трафика, но и входящего (в отличие от ACL для NAT, например).
То есть если придут пакеты не от 10.1.1.0, а от 10.2.2.2, он не будет обработан и дешифрован.

То бишь, если мы генерируем трафик с хоста с адресом 10.0.0.0 на 10.1.1.0, то он и только он будет шифроваться и отправляться именно в IPSec-туннель. Любой другой пойдёт простым путём.

Заметим, что шифрование, происходит практически в самую последнюю очередь, после маршрутизации.
И это, кстати, очень важный момент. Вам недостаточно маршрута до публичного адреса пира (200.0.0.1). Нужен маршрут до 10.1.1.0 пусть даже он дефолтный. Иначе пакет будет отброшен в соответствии с обычными правилами маршрутизации.
Как бы странно это ни казалось, но трафик в локальную сеть у вас должен быть “зарулен”, например, в Интернет. При этом приватные пакет, которые уже вот-вот должны быть отправлены к провайдеру и там отброшены, в последний момент шифруется, получая публичные адреса.
Кстати, есть таблица с порядком следования операций, производимых над трафиком.

Последний шаг – привязка карты шифрования к интерфейсу. Пока вы этого не сделаете механизм не будет работать.

interface FastEthernet0/0
crypto map MAP1

С обратной стороны нужно произвести симметричную настройку.
Поэтому просто применяем следующую конфигурацию на R3:

crypto isakmp policy 1
encr aes
authentication pre-share
crypto isakmp key CISCO address 100.0.0.1
!
!
crypto ipsec transform-set AES128-SHA esp-aes esp-sha-hmac
!
crypto map MAP1 10 ipsec-isakmp
set peer 100.0.0.1
set transform-set AES128-SHA
match address 101

Interface FastEthernet0/1
crypto map MAP1

Access-list 101 permit ip host 10.1.1.0 host 10.0.0.0

Вот и всё.

Но сколько бы вы после ни смотрели show crypto session или show crypto isakmp sa , вы увидите только Down . Туннель никак не поднимается.
Счётчики show crypto ipsec sa . Так же по нулям.

R1#sh crypto session

Interface: FastEthernet0/0
Session status: DOWN
Peer: 200.0.0.1 port 500
Active SAs: 0, origin: crypto map

R1#sh crypto isakmp sa

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

R1#ping 10.1.1.0 source 10.0.0.0

Sending 5, 100-byte ICMP Echos to 10.1.1.0, timeout is 2 seconds:
Packet sent with a source address of 10.0.0.0
.!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 60/94/160 ms

И как только вы это сделали, вас ждёт успех:

R1#sh crypto session
Crypto session current status

Interface: FastEthernet0/0
Session status: UP-ACTIVE
Peer: 200.0.0.1 port 500
IKE SA: local 100.0.0.1/500 remote 200.0.0.1/500 Active
IPSEC FLOW: permit ip host 10.0.0.0 host 10.1.1.0
Active SAs: 2, origin: crypto map

R1#sh crypto isakmp sa
dst src state conn-id slot status
200.0.0.1 100.0.0.1 QM_IDLE 1 0 ACTIVE

Начальная конфигурация: «IPsec»
Маршрутизатор R1 стоит в центральном офисе.
Маршрутизатор R3 - это маршрутизатор в одном из филиалов.
К схеме добавляется маршрутизатор R4 - второй филиал.

Задание:
1. Настроить туннель IPsec с использованием crypto-map между R4 и R1:
- Политики защиты данных такие же, как и для туннеля между R3 и R1.
2. Добавить соответствующие настройки для того чтобы R3 и R4 также могли обмениваться данными:
- Данные между филиалами за R3 и R4 должны передаваться через центральный маршрутизатор R1

Конфигурация: «IPsec»

Примечание:
Задача может быть решена, как теоретически, так и практически.
Если Вы будете пробовать задачу на практике, то внимательно соблюдайте условия задачи.

Условия задачи:
Маршрутизатор R1 стоит в центральном офисе и к нему будут подключены 3 филиала (для данной задачи достаточно маршрутизаторов R1, R2, R3. R3 - в роли одного из филиалов). В филиалах используются маршрутизаторы с разными возможностями, и необходимо использовать разные политики IPsec. Всего есть 3 различные политики.
На маршрутизаторе R3, кроме туннеля в центральный офис также есть несколько туннелей с партнерами. Поэтому тут тоже созданы различные политики.
Трафик передается только из филиалов в центральный офис, между филиалами коммуникаций нет.

Со стороны филиала R3 в центральный офис R1 генерируются данные, которые инициируют туннель VPN.
Вопрос: Какую политику защиты данных будут использовать маршрутизаторы для построения туннеля между собой?

Схема: «итоговая схема задачи 7.1»
Конфигурации устройств: на сайте проекта

Описание проблемы:
Не передаются данные между R1 и R4.

Задание:
Найти ошибку и исправить конфигурацию так, чтобы туннель между R1 и R4 установился и передавался трафик между R1 и R4.

Конфигурация: на сайте проекта

Описание проблемы:
После настройки GRE over IPSec между R1 и R3, всё прекрасно работает, трафик между R1 и R3 (c 10.0.0.0 на 10.1.1.0) передается.
Однако, через несколько дней, когда администратор хотел посмотреть состояние VPN, обнаружилось, что на маршрутизаторах вообще нет установленных SA.
Соответственно, трафик между R1 и R3 не шифруется.

Задание:
Необходимо проверить настройки, исправить конфигурацию и сделать так, чтобы трафик шифровался (трафик между loopback-интерфейсами 10.0.0.0 и 10.1.1.0).

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

interface Tunnel0
tunnel mode ipip

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

Схема: «GRE_over_IPSec»

Задание:
Изменить исходную конфигурацию GRE over IPSec и настроить GRE over IPsec без использования crypto-map.

DMVPN

Апофеоз сегодняшнего выпуска – DMVPN (Dymamic Multipoint VPN). До сих пор речь была об универсальных вендоронезависымых вещах. К сожалению, DMVPN – вещь сугубо цисковская и открытых адекватных аналогов пока не имеет (поправьте, если ошибаюсь).

В предыдущих частях мы решили проблему с безопасностью передаваемых данных – теперь мы их шифруем – и с IGP – посредством GRE over IPSec мы используем протоколы динамической маршрутизации.
Осталась последняя проблема – масштабируемость.
Хорошо, когда у вас вот такая сеточка:

По два туннеля на каждом узле и всё.
Добавляем ещё один узел:

И ещё один:

Нужно уже гораздо больше туннелей для получения полносвязной топологии. Типичная проблема со сложностью m*(m-1)/2.
Если не использовать Full-Mesh, а обратиться к топологии Hub-and-Spoke с одной центральной точкой, то появляется другая проблема – трафик между любыми филиалами будет проходить через центральный узел.

DMVPN позволяет решить обе проблемы.
Суть такая: выбирается центральная точка Hub (или несколько). Она будет сервером, к которому будут подключаться клиенты (Spoke) и получать всю необходимую информацию. При этом:

1) Данные будут зашифрованы IPSec
2) Клиенты могут передавать трафик непосредственно друг другу в обход центрального узла
3) Только на центральном узле необходим статический публичный IP-адрес. Удалённые узлы могут иметь динамический адрес и находиться даже за NATом, используя адреса из частных диапазонов (Технология NAT Traversal). Но при этом возникают ограничения по части динамических туннелей.

Это всё средоточие мощи GRE и IPSec, сдобренное NHRP и IGP.

Теория и практика DMVPN

Абстрагируясь от нашей старой сети, возьмём в рассмотрение только Москву, сеть Интернет, которую будет эмулировать маршрутизатор Балаган-Телеком, и собственно филиалы в Новосибирске, Томске и Брно:

Новый IP-план:
Подсети, выделенные для подключения к интернету филиалов:

Для туннельных интерфейсов возьмём внутреннюю сеть:

И назначим также адреса Loopback для них:

Идея заключается в том, что на центральном узле будет один единственный динамический туннель, который мы настроим в самом начале, а при добавлении новых удалённых точек, здесь не нужны изменения – ни добавлять новые туннельные интерфейсы, ни перенастраивать уже существующий.
Фактически при добавлении новых узлов настраивать нужно только их.
Везде запускается протокол NHRP – NBMA Next Hop resolution Protocol.
Он позволяет динамически изучать адреса удалённых точек, который желают подключиться к основной.
На нём и основана возможность реализации multipoint VPN. Хаб (центральный узел) здесь выступает как сервер (NHS – Next-Hop Server), а все удалённые узлы будут клиентами (NHC – Next-Hop Client).
Звучит это сложно. На пальцах объяснить тоже не получится. Надо лишь один раз настроить и посмотреть, как бегают пакеты.

Конфигурация хаба:

interface Tunnel0


ip nhrp network-id 1

tunnel mode gre multipoint

По порядку:
ip address 172.16.254.1 255.255.255.0
ip nhrp map multicast dynamic – Динамическое изучение данных NHRP от клиентов. Поскольку клиентов у нас множество и они могут быть с динамическими адресами, на хабе нельзя задать явное соответствие внутренних и внешних адресов.
ip nhrp network-id 1 – Определяем Network ID – просто идентификатор, который необязательно должен быть одинаковым на всех узлах DMVPN (похож на OSPF Router-ID).
tunnel source FastEthernet0/1.6 – наследие GRE – привязка к физическому интерфейсу.
tunnel mode gre multipoint – Туннель на центральном узле будет терминировать все туннели от удалённых точек. То есть он будет точка-многоточка (Point-to-MultiPoint).

Конфигурация филиала:

interface Tunnel0



ip nhrp network-id 1
ip nhrp nhs 172.16.254.1
ip nhrp registration no-unique

tunnel mode gre multipoint

По порядку:
ip address 172.16.254.2 255.255.255.0 – IP-адрес из нужного диапазона.
ip nhrp map 172.16.254.1 198.51.100.2 – Статическое соотношение внутреннего и внешнего адресов хаба.
ip nhrp map multicast 198.51.100.2 мультикастовый трафик должен получать хаб.

Без этой команды у вас будут довольно интересные симптомы проблемы.
Вот вы запустили OSPF, пиринг поднимается, хаб и филиалы переходят в состояние Full, обменялись маршрутами, и вы уже радуетесь, что всё отлично, и тут бац – пинг пропадает, пиринг падает, но только с одной стороны, мол истёк dead-timer.

*Mar 1 01:51:20.331: %OSPF-5-ADJCHG: Process 1, Nbr 172.16.255.2 on Tunnel0 from FULL to DOWN, Neighbor Down: Dead timer expired
msk-arbat-gw1#
*Mar 1 01:51:25.435: %OSPF-5-ADJCHG: Process 1, Nbr 172.16.255.2 on Tunnel0 from LOADING to FULL, Loading Done

Что за фигня?
Смотрим дебаг, смотрим дампы

*Mar 1 01:53:44.915: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.4 from 172.16.2.1
*Mar 1 01:53:44.919: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.7 from 172.16.2.33
*Mar 1 01:53:44.923: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.5 from 172.16.2.17
*Mar 1 01:53:44.923: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.8 from 172.16.2.129
*Mar 1 01:53:44.963: OSPF: Send hello to 224.0.0.5 area 0 on Tunnel0 from 172.16.254.1
msk-arbat-gw1#
*Mar 1 01:53:54.919: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.4 from 172.16.2.1
*Mar 1 01:53:54.923: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.7 from 172.16.2.33
*Mar 1 01:53:54.927: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.5 from 172.16.2.17
*Mar 1 01:53:54.931: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.8 from 172.16.2.129
*Mar 1 01:53:54.963: OSPF: Send hello to 224.0.0.5 area 0 on Tunnel0 from 172.16.254.1
msk-arbat-gw1#
*Mar 1 01:54:04.919: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.4 from 172.16.2.1
*Mar 1 01:54:04.927: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.7 from 172.16.2.33
*Mar 1 01:54:04.931: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.5 from 172.16.2.17
*Mar 1 01:54:04.935: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.8 from 172.16.2.129
*Mar 1 01:54:04.963: OSPF: Send hello to 224.0.0.5 area 0 on Tunnel0 from 172.16.254.1



На 5 OSPF Hello от хаба только один Hello от филиала.
Как вы уже поняли, маршрутизатор просто не может сообразить куда посылать мультикастовые сообщения на адрес 224.0.0.5, хаб их не получает и дёргает OSPF-сессию.

ip nhrp network-id 1 – Network ID. Не обязательно должен совпадать с таким же на хабе.
ip nhrp nhs 172.16.254.1 – Статически настроенный адрес NHRP сервера – хаба. Именно поэтому в центре нам нужен статический публичный адрес. Клиенты отправляют запрос на регистрацию на хаб 172.16.254.1. Этот запрос содержит настроенный локальный адрес туннельного интерфейса, а также свой публичный адрес (случай, когда клиент находится за NAT пока не рассматриваем).
Полученную информацию хаб заносит в свою NHRP-таблицу соответствия адресов. Эту же таблицу он распространяет по запросу любому Spoke-маршрутизатору.

ip nhrp registration no-unique – если адрес в филиалах выдаётся динамически, эта команда обязательна.
tunnel source FastEthernet0/0 – привязка к физическому интерфейсу.
tunnel mode gre multipoint – указываем, что тип туннеля mGRE – это позволит создавать динамически туннели не только до хаба, но и до других филиалов.

У нас ситуация простая – без NAT – и мы можем уже сейчас проверить состояние туннелей.

msk-arbat-gw1#sh int tun 0
Tunnel0 is up, line protocol is up
Hardware is Tunnel
Internet address is 172.16.254.1/24
MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source 198.51.100.2 (FastEthernet0/1.6), destination UNKNOWN
Tunnel protocol/transport multi-GRE/IP
Key disabled, sequencing disabled
Checksumming of packets disabled

msk-arbat-gw1#ping 172.16.254.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.254.2, timeout is 2 seconds:
!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 176/213/284 ms

msk-arbat-gw1#sh ip nhrp brief

msk-arbat-gw1#sh ip nhrp
172.16.254.2/32 via 172.16.254.2, Tunnel0 created 00:09:48, expire 01:50:11
Type: dynamic, Flags: authoritative unique registered
NBMA address: 198.51.101.2

Nsk-obsea-gw1#sh ip nhrp brief
Target Via NBMA Mode Intfc Claimed

OSPF

То есть связность уже обеспечена, но работать филиалы пока не могут – не настроена маршрутизация.

Тут для каждого протокола свои всплывают тонкости.
Давайте рассмотрим процесс настройки OSPF, для примера.

Поскольку мы имеем широковещательную L2 сеть на туннельных интерфейсах, указываем явно тип сети Broadcast на туннельных интерфейсах на всех узлах:

Кроме того в такой сети должен выбираться DR. Логично, чтобы им стал хаб. Всем Spoke-маршрутизаторам запрещаем участие в выборах DR:

Ну и, естественно, определяем анонсируемые сети.

router ospf 1
network 172.16.0.0 0.0.255.255 area 0

Сети анонсируются:

msk-arbat-gw1#sh ip route

Gateway of last resort is 198.51.100.1 to network 0.0.0.0

172.16.0.0/16 is variably subnetted, 7 subnets, 3 masks
C 172.16.2.128/30 is directly connected, FastEthernet0/1.8
C 172.16.255.1/32 is directly connected, Loopback0
C 172.16.254.0/24 is directly connected, Tunnel0
C 172.16.2.32/30 is directly connected, FastEthernet0/1.7
C 172.16.2.16/30 is directly connected, FastEthernet0/1.5
C 172.16.2.0/30 is directly connected, FastEthernet0/1.4
O 172.16.255.128/32 via 172.16.254.2, 00:05:14, Tunnel0
198.51.100.0/28 is subnetted, 1 subnets
C 198.51.100.0 is directly connected, FastEthernet0/1.6
S* 0.0.0.0/0 via 198.51.100.1

Пинг проходит

msk-arbat-gw1#ping 172.16.255.128

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.255.128, timeout is 2 seconds:
!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 60/70/80 ms

Вот так выглядят пакеты, передающиеся через сеть Интернет:

* Дамп с nsk-obsea-gw1 fa0/0

Проверяем, как у нас проходит пинг от одного филиала до другого:

nsk-obsea-gw1#ping 172.16.255.132

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.255.132, timeout is 2 seconds:
!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 132/231/492 ms

Nsk-obsea-gw1#traceroute 172.16.255.132

Type escape sequence to abort.
Tracing the route to 172.16.255.132

1 172.16.254.3 240 msec * 172 msec

Nsk-obsea-gw1#sh ip nhrp br
Target Via NBMA Mode Intfc Claimed
172.16.254.1/32 172.16.254.1 198.51.100.2 static Tu0

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

Что происходит в этот момент?
1) Отправляем пинг на адрес Loopback-интерфейса в Томске
2) Согласно таблице маршрутизации, следующий хоп

Last update from 172.16.254.3 on Tunnel0, 00:18:47 ago
Routing Descriptor Blocks:
* 172.16.254.3, from 172.16.255.132, 00:18:47 ago, via Tunnel0

Это адрес из сети, непосредственно подключенной к интерфейсу Tunnel 0

Routing Descriptor Blocks:
* directly connected, via Tunnel0

3) Согласно настройкам интерфейса здесь используется NHRP. Смотрим таблицу соответствия, полученную от хаба

nsk-obsea-gw1#sh ip nhrp brief
Target Via NBMA Mode Intfc Claimed
172.16.254.1/32 172.16.254.1 198.51.100.2 static Tu0

Как видите, адрес 172.16.254.3 nhrp неизвестен .
Поэтому пакет ICMP отправляется на статически настроенный хаб – 198.51.100.2:

msk-arbat-gw1, fa0/1:

А хаб сразу же перенаправляет запрос на нужный адрес:

msk-arbat-gw1, fa0/1:

4) Одновременно с этим маршрутизатор-клиент в Новосибирске отправляет NHRP-запрос, мол кто укрывает адрес 172.16.254.3:

msk-arbat-gw1, fa0/1:

5) Хаб обладает этим знанием:

msk-arbat-gw1#sh ip nhr br
Target Via NBMA Mode Intfc Claimed
172.16.254.2/32 172.16.254.2 198.51.101.2 dynamic Tu0
172.16.254.3/32 172.16.254.3 198.51.102.2 dynamic Tu0

И отправляет эту информацию в NHRP-ответе:

msk-arbat-gw1, fa0/1:

Больше Хаб не встревает в разговор двух споков.

6) ICMP запрос пришёл в Томск:

tmsk-lenina-gw1, fa0/0:

Несмотря на то, что во внешнем заголовке IP адрес источника – это адрес хаба, внутри фигурирует изначальный адрес Новосибирского маршрутизатора:

7)Томск тоже пока не знает ничего об адресе 172.16.254.2, пославшем ICMP-запрос.

Target Via NBMA Mode Intfc Claimed
172.16.254.1/32 172.16.254.1 198.51.100.2 static Tu0

Поэтому ICMP-ответ он отправляет тоже на хаб:
tmsk-lenina-gw1, fa0/0:

8) Следом за ним он интересуется о публичном адресе отправителя:

tmsk-lenina-gw1, fa0/0:

9)Ну и хаб, естественно, отвечает:

tmsk-lenina-gw1, fa0/0:

10) Сейчас на всех узлах актуальная информация NHRP:

msk-arbat-gw1(config-if)#do sh ip nhr br
Target Via NBMA Mode Intfc Claimed
172.16.254.2/32 172.16.254.2 198.51.101.2 dynamic Tu0
172.16.254.3/32 172.16.254.3 198.51.102.2 dynamic Tu0

Target Via NBMA Mode Intfc Claimed
172.16.254.1/32 172.16.254.1 198.51.100.2 static Tu0
172.16.254.3/32 172.16.254.3 198.51.102.2 dynamic Tu0

tmsk-lenina-gw1(config-if)#do sh ip nh br
Target Via NBMA Mode Intfc Claimed
172.16.254.1/32 172.16.254.1 198.51.100.2 static Tu0
172.16.254.2/32 172.16.254.2 198.51.101.2 dynamic Tu0

Как видите, распространение происходит не автоматически, а по запросу, причём инициаторами являются только клиенты, потому что фактически, только они знают, куда обращаться (хаб изначально не знает о клиентах ничего)

11) Следующий ICMP-запрос он уже отправит по-новому:

nsk-obsea-gw1#sh ip route 172.16.255.132
Routing entry for 172.16.255.132/32
Known via «ospf 1», distance 110, metric 11112, type intra area
Last update from 172.16.254.3 on Tunnel0, 00:20:24 ago
Routing Descriptor Blocks:
* 172.16.254.3, from 172.16.255.132, 00:20:24 ago, via Tunnel0
Route metric is 11112, traffic share count is 1

Подсеть 172.16.254.0 подключена к интерфейсу Tunnel 0

nsk-obsea-gw1#sh ip route 172.16.254.3
Routing entry for 172.16.254.0/24
Known via «connected», distance 0, metric 0 (connected, via interface)
Routing Descriptor Blocks:
* directly connected, via Tunnel0
Route metric is 0, traffic share count is 1

12) Мы немного повторяемся, но… Интерфейс Tunnel 0 является mGRE и согласно таблицы NHRP весь трафик, для которого следующим хопом является 172.16.254.3 должен быть инкапсулирован в GRE и внешний IP-заголовок с адресом назначения 198.51.102.2 (В качестве адреса источника будет выбран адрес физического интерфейса – 198.51.101.2):

nsk-obsea-gw1(config-if)#do sh ip nhr br
Target Via NBMA Mode Intfc Claimed
172.16.254.1/32 172.16.254.1 198.51.100.2 static Tu0
172.16.254.3/32 172.16.254.3 198.51.102.2 dynamic Tu0

tmsk-lenina-gw1, fa0/0:

Gateway of last resort is 198.51.101.1 to network 0.0.0.0

Тут важно понимать, что несмотря на то, что общение между филиалами осуществляется в обход центрального узла, хаб однако несёт тут жизненно важную вспомогательную функцию и без него ничего работать не будет: он предоставляет клиентам таблицу NHRP, а также анонсирует все маршруты – филиалы распространяют маршрутную информацию не непосредственно друг другу, а через хаб.

Актуальная на данный момент конфигурация узлов:

msk-arbat-gw1
interface Tunnel0
ip address 172.16.254.1 255.255.255.0
no ip redirects
ip nhrp map multicast dynamic
ip nhrp network-id 1
ip ospf network broadcast
ip ospf priority 10
tunnel source FastEthernet0/1.6
tunnel mode gre multipoint

Nsk-obsea-gw1
interface Tunnel0
ip address 172.16.254.2 255.255.255.0
no ip redirects
ip nhrp map 172.16.254.1 198.51.100.2
ip nhrp map multicast 198.51.100.2
ip nhrp network-id 1
ip nhrp nhs 172.16.254.1
ip ospf network broadcast
ip ospf priority 0
tunnel source FastEthernet0/0
tunnel mode gre multipoint

Tmsk-leneina-gw1
interface Tunnel0
ip address 172.16.254.3 255.255.255.0
no ip redirects
ip nhrp map 172.16.254.1 198.51.100.2
ip nhrp map multicast 198.51.100.2
ip nhrp network-id 1
ip nhrp nhs 172.16.254.1
ip ospf network broadcast
ip ospf priority 0
tunnel source FastEthernet0/0
tunnel mode gre multipoint
end

На данный момент решены следующие проблемы:
1) Связность. Филиалы подключены и доступны.
2) Маршрутизация. Через mGRE туннели успешно запущены IGP.
3) Масштабируемость. При добавлении нового spoke-маршрутизатора настраивается только он сам и нет необходимости лезть в конфигурацию уже существующих узлов.
4) Разгрузили хаб – через него передаётся только служебный трафик.

Осталось уладить вопрос с безопасностью.

IPSec

Решается это как и прежде – шифрованием.
Если для Site-to-Site VPN мы ещё могли использовать pre-shared key, потому что мы жёстко задавали адрес IPSec-пира, то в случае DMVPN нам нужна гибкость, а заранее мы не знаем адреса соседей.
В связи с этим рекомендуется использование сертификатов. На xgu есть хорошая по центру сертификатов на cisco.

Но мы для упрощения возьмём всё же настройку с pre-shared ключом.

crypto isakmp policy 1
authentication pre-share

От рассмотренных выше Tunnel Protection и VTI она будет отличаться использованием шаблонного адреса:

crypto isakmp key DMVPNpass address 0.0.0.0 0.0.0.0

Опасность здесь в том, что установить IPSec-сессию с хабом, зная ключ, может любое устройство

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

crypto ipsec transform-set AES128-SHA esp-aes esp-sha-hmac
mode transport

Crypto ipsec profile DMVPN-P
set transform-set AES128-SHA

Далее созданный профиль применяется на туннельный интерфейс. Настройка на всех узлах одинаковая.

interface Tunnel0
tunnel protection ipsec profile DMVPN-P

Теперь пакеты, передающиеся через Интернет будут зашифрованы:
msk-arbat-gw1, fa0/1:

Только не вздумайте поставить tunnel mode ipsec ipv4 :)

IPSec-туннели и карты шифрования будут создаваться динамически для сеансов передачи данных между филиалами и будут перманентными для каналов Hub-Spoke.

NAT-Traversal

Тут мы не будем вдаваться в принципы работы NAT-T Передам только суть: за счёт дополнительного UDP-заголовка IPSec может строить туннель сквозь NAT. Это позволяет строить VPN даже на тех узлах, где у вас нет публичного адреса.
Нет необходимости этот функционал каким-то особым образом активировать и настраивать – он работает по умолчанию.
Усложним схему добавлением ещё одного маршрутизатора в Брно.

Допустим, это провайдерская железка, осуществляющая натирование. То есть фактически на роутере в филиале у нас будет динамический адрес из приватного диапазона на физическом интерфейсе. GRE в чистом виде не может построить VPN при таких условиях, IPSec может, но сложно настраивать. mGRE в связке с IPSec может легко!

Давайте посмотрим как выглядит таблица NHRP в этом случае:

msk-arbat-gw1#show ip nhrp brief
Target Via NBMA Mode Intfc Claimed
172.16.254.4/32 172.16.254.4 10.0.0.2 dynamic Tu0

То есть изучил он всё-таки приватный адрес, выделенный провайдером.
Надо заметить, что в таблице маршрутизации должен быть маршрут до этого приватного адреса, выданного провайдером в филиале, пусть даже дефолтный.

На туннельном интерфейсе у нас активирован IPSec, следовательно должны быть карты шифрования:

msk-arbat-gw1#show crypto map
Crypto Map «Tunnel0-head-0» 65537 ipsec-isakmp
Map is a PROFILE INSTANCE.
Peer = 198.51.103.2
Extended IP access list
access-list permit gre host 198.51.100.2 host 10.0.0.2
Current peer: 198.51.103.2
Security association lifetime: 4608000 kilobytes/3600 seconds
PFS (Y/N): N
Transform sets={
AES128-SHA,
}
Interfaces using crypto map Tunnel0-head-0:
Tunnel0

Таким образом шифрованный туннель строится между 198.51.100.2 и 198.51.103.2, дальше, данные по-прежнему шифрованные за счёт NAT-T в туннеле идут до 10.0.0.2. А дальше вы уже знаете.

Толковая подробная статья по .

Сценарий:
Сеть DMVPN была полностью работоспособной, всё работало корректно.
Но после перезагрузки хаба msk-arbat-gw1 началось странное поведение.

Задание:
1. Проверить работоспособность сети.
2. Перезагрузить хаб
3. После перезагрузки проверить работоспособность сети ещё раз
4. Устранить проблему:
4.1. (минимум) Сделать сеть снова работоспособной
4.2. Сделать так, чтобы сеть восстанавливалась автоматически, после того как хаб снова появится.

Для всевозможных туннелей это совершенно типичная проблема.

Почему же работают пинг и яндекс?
Пакеты ICMP Request и Relpy имеют размер от 32 до 64 байтов, ya.ru возвращает очень мало информации, которая вполне укладывается в допустимый размер 1500 вместе со всеми заголовками.

подкаст

Добавить метки