Comments 34
Одно время провайдеры нередко блокировали gre-пакеты.
Даже не со зла, чисто по незнанию что это за зверь такой.
Или это другое?
Нет, это именно оно, и если провайдер блокирует GRE, то тесты на определенном этапе у вас проходить не будут
В данном примере идет тройная инкапсуляция UserIP > GRE(47) > AH(51) > ESP(50)
Провайдер увидит только верхний уровень - пакеты протокола ESP
AH не используется
Используется, Вы его просто не видите.
Вот если в "Auth. Algorithms" выбрать None или использовать GCM шифрование, то да - его не будет.
Да, Вы правы. Спасибо !
Впрочем ажжите ! Мы говорим о разном ! AH(51) есть ничто иное как альтернатива ESP (50)
А вот ESP Auth является частью заголовков протокола ESP (50) :)
Authentication Header (AH) protocol is only about authentication (inserts a hash to confirm integrity). Encapsulated Security Protocol (ESP) can be used for either authentication, confidentiality, or both. Their function is a bit different. ESP can take an entire packet (including an AH one), encapsulate it, apply encryption to achieve confidentiality, while also adding its own payload hash to ensure integrity. AH can be used with ESP.
Возникает вопрос - если у ESP есть собственные функции аутентификации и шифрования, для чего необходимо дополнительное использование AH (51) ?
Все, разобрался ! Все как Вы и говорите !
AH я собственно сам и включил и он работает в паре с ESP. GCM AH не поддерживает по умолчанию.
Почаще бы так ! Спасибо еще раз :)
Увлекательно было читать, руки зачесались повторить для теста). У вас в начале упомянут DHCP, каких то настроек для него в статье не увидел, или пропустил? Т.з. выглядит отлично, но несколько не понятно зачем такой конфиг сети может быть нужен.
DHСP ? А, это для автоматической настройки внешнего интерфейса маршрутизатора (Обычный DHCP клиент). У Микротика он из коробки включен, этого как правило и достаточно
Иногда провайдер требует PPP, вот тогда нужно будет перенастроить
Касательно для чего все это нужно ? - Было любопытно посмотреть Libreswan :) Первый раз делал. Ну и может пригодится когда
Ник у вас оч интересный :) Когда-то в школьные годы деньги на Dial-Up откладывались из денег на обеды. Провайдером выступал Sampo :)
Придумал Вам бизнес кейс, смотрите:
Есть некая организация в Москве. У нее есть сотрудники разбросанные по соседним странам.
Есть некие внутренние ресурсы опубликованные в публичном облаке (почта, документооборот, unified comms, что угодно)
Доступ к этим ресурсам разрешен только с публичных адресов этой компании
Проблема:
Удаленные сотрудники не получат доступа к этим ресурсам, не смотря на то, что смогут резолвить их FQDNs
Решение:
Реализация удаленного доступа для сотрудников и маршрутизация их трафика через периметр нашей компании
Проблема:
У компании ограниченная полоса пропускания на внешних каналах и забивать их лишним трафиком не хотелось бы. К тому же, гонять трафик, скажем, из Казахстана в Россию и обратно в Казахстан - дело такое себе
Решение:
Сплит-туннель позволяющий маршрутизировать лишь определенные блоки в наш с вами туннель
Надеюсь стало понятнее
Уже позже я вспомнил, зачем же я gre поднимал для одной организации - по нему широковещательные ходят и как раз в самповской сети надо было связать несколько точек, чтобы была единая сеть для smb
Кастельно GRE - он под данное ТЗ абсолютно избыточен. Но давайте рассмотрим где и зачем он может пригодиться
Предположим у вас два офиса и нужно обеспечить связность
Предположим каждый из офисов имеет по два аплинка через разных ISP
Предположим каждый из офисов использует PA (Provider Aggregatable) адреса
Предположим вам необходимо обеспечить отказоустойчивость линков с минимальной сходимостью
Вот здесь GRE и пригодится чтобы обеспечить установку соседства OSPF
.
Неофитам наверняка непонятна схема размещения технических средств. И мне в том числе. Черкните пожалуйста несколько строк или добавьте схему в статью.
Спасибо ! С удовольствием поправлю !
Только подождите - а что именно непонятно ? Или сложность в том, что неясно что есть FW1 и что есть FW2 ?
И так, мне как "начинающему" строителю схем взаимодействия между удаленными офисами непонятно - какой перечень оборудования участвует в схеме? Личные сотовые телефоны сотрудников; ПЭВМ, подключенные к локальной сети филиала; мест(о/а) нахождения серверов с линуксом; мест(о/а) нахождения микротиков?
Спасибо !
Под личные сотовые телефоны и домашних пользователей придется строить Hub and Spoke топологию (это повод к написанию третьего дополнения к этой статье, второе опишет необходимость использования GRE)
Под ПЭВМ, подключенные к локальной сети филиала подойдет Site to Site топология описанная в данной статье.
Линукс, в данном случае, стоит в головном офисе (Не спрашивайте почему ! Legacy архитектура :) Все таки изначально ТЗ было иным и полностью нераскрыто) Микротик - в филиале
Спасибо еще раз, именно благодаря комментариям изменилось ТЗ и появились идеи дальнейшего развития данной публикации
Ерунда какая то написана, строить сеть на устаревшем, медленном VPN протоколе, который еще и блокируется провайдером.
Как скажите, спорить я не хочу
Представьте себе ситуацию - у вас Hub and Spoke для клиентов с динамическим сорсом (что подразумевает, что "наружу" вы будете торчать абсолютно голой жопой :) )
Что вы будете делать ? Аутентификацию по PSK ? А если его скомпроментируют ? А если пользователь уволится ?
В идеале вы хотите следующее (забудем про RSA Secure ID и вендорские решения ибо это дорого и сфокусируемся на OpenSource. Понятно что в нем потенциально большее количество уязвимостей и меньший функционал)
Первый фактор - Аутентификация по сертификату, желательно с проверкой серийника машинного сертификата. Что делать если человек увольняется ? Отзывать сертификаты. Как проверять ? CRL/OSCP. Как менеджерить ? Скажем RADIUS. Не забудьте запретить выгрузку сертификатов.
Второй фактор - допустим LDAP. Здесь вам нужен коннектор к каталогу. Желательно SSO ибо вводить руками пароли, там где этого можно избежать - странно.
Важно чтобы последовательно проверялись ОБА фактора и дабы избежать LDAP Harvesting RADIUS/CERT проверять желательно первым и в случае отказа останавливать все дальнейшие проверки.
Как я это буду реализовывать на Libreswan ? Понятия не имею ! Я его знаю 2 дня :)
Здесь пишут что это возможно. А вы говорите говно ваш ойписек
Чем не устраивает встроенный в mikrotik новый, быстрый VPN протокол wireguard ? Зачем все эти сложности с GRE ?
Всем устраивает :) Энтерпрайз только не всегда его поддерживает. Как только появится поддержка у Palo Alto, Fotinet, Check Point, Arista, Cisco и Juniper - можно будет обсуждать. Так что с точки зрения общего развития подрастающего поколения IPSec, в данное время, более интересен.
GRE, как я уже объяснял, необходим в частных случаях. Сложности особой в дополнение к Transport/Tunnel IPSec - не представляет, а вот понимания и практических навыков кому-то и добавит
Wireguard соединение является одновременно сервером и клиентом. Соединить два микротикс вообще нет проблем, под ubuntu есть готовые docker контейнеры для wireguard с web интерфейсом для генерации конфигурационых файлов для различных клиентов wireguard (windows, android и т.д.) Сам протокол wireguard принципиально отличается от более старых VPN протоколов.
Я не спорю, решение имеет место быть. На производительность я его не тестировал, подозреваю что он может быть быстрее IPSec.
Свою точку зрения строю исходя из полезности (с точки зрения общего развития и последующего трудоустройства подрастающего поколения) и комплаенса
Почему только под убунту? Докер тем и хорош, что нет зависимости от дистрибутива.
К этому процессу есть пара вопросов.
1) Если мы делаем только site-to-site, а не roadwarrior соединения - то почему бы не настроить ipsec прямо интерфейсе настройки gre тоннеля? Ключ всё равно будет использоваться только в этом конкретном соединении, с других адресов с ним не подключатся. При закрытии филиала - просто убивается тоннель и ключ уже не важен.
2) Почему не воткнуть Микротик в головном офисе, зачем дополнительные страдания с линуксовым libreswan?
1) Если мы делаем только site-to-site, а не roadwarrior соединения - то почему бы не настроить ipsec прямо интерфейсе настройки gre тоннеля? Ключ всё равно будет использоваться только в этом конкретном соединении, с других адресов с ним не подключатся. При закрытии филиала - просто убивается тоннель и ключ уже не важен.
Да ! Да ! И еще раз Да ! Именно так и нужно !
Не спрашивайте почему у меня GRE. Изначальная версия статьи была абсолютно иной и мне было любопытно посмотреть Libreswan. Переписывать все абсолютно с нуля ? Может и соберусь :) Альтернативой придумал юз кейс с двумя линками и динамической маршрутизацией
2) Почему не воткнуть Микротик в головном офисе, зачем дополнительные страдания с линуксовым libreswan?
Конечно воткните ! Страдания никчему ! Сделаю оговорку про MFA и неуверен что Микротик повзолит аутентифицировать road warriors, так как хотелось бы. Впрочем на данный момент из подтверждений что Libreswan сможет у меня лишь последний параграф статьи на RedHat.
Плюс, рассматривая оба продукта, человек может получить базу как работать и с тем, и с другим. Не будет у организации денег на микротики, можно поднять libreswan на виртуалках дабы сэкономить на серверах. А так да, вы правы. Микротик удобнее наличием GUI и по функционалу не сильно и отличается
У нас из за определенных событий ни один "старый" vpn не работал дней 10, все блокировалось провайдерами, спасал только wireguard, с ним никаких проблем не было.
Реализация удаленного доступа для предприятия через IPSec (Libreswan + MikroTik) — Часть Первая