Vpn тоннель в обе стороны настройка: Прямой VPN-туннель между двумя компьютерами находящимися за NAT провайдеров с использованием UDP hole punching

Настраиваем VPN. Часть 1 — Общие вопросы

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

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

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

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

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

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

PPTP

PPTP (Point-to-Point Tunneling Protocol, туннельный протокол точка-точка) — один из наиболее известных клиент-серверных протоколов, получил широкое распространение благодаря тому, что начиная с Windows 95 OSR2 PPTP-клиент был включен в состав ОС. В настоящее время поддерживается практически всем спектром систем и устройств, включая роутеры и смартфоны (клиент удален из последних версий macOS и iOS).

Технически PPTP использует два сетевых соединения: канал управления, работающий через TCP и использующий порт 1723 и GRE-туннель для передачи данных. Из-за этого могут возникать сложности с использованием в сетях мобильных операторов, проблема с одновременной работой нескольких клиентов из-за NAT и проблема проброса PPTP соединения через NAT.

Еще одним существенным недос

Туннели и VPN, устойчивые к DPI / Хабр

Мы живем в интересное время. Я бы даже сказал, в удивительное. По одну сторону мы видим неких лиц, которые очень хотят знать, о чем между собой разговаривают другие люди, и очень хотят указывать им, что можно читать, а что нельзя. С другой стороны граждане, которые хотят отстоять свои права тайны личной переписки и свободного получения информации, и не хотят, чтобы факты этой самой переписки и получения этой самой информации были использованы против них. Бонусом страдает огромное количество сторонних сайтов, сервисов и бизнесов, которых задевает «ковровыми блокировками».

Но нет, эта статья не об обществе, а о технологиях.

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

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

На Хабре неоднократно в комментариях озвучивали прогнозы как дальше может происходить борьба с технологиями шифрования для обычных граждан. Анализируя озвученные мысли и посмотрев на свидетельства из других стран, я попробовал предположить, в какую сторону могут дальше двинуться меры по ограничению связи. DistortNeo и shifttstas подкинули еще несколько интересных идей, и в итоге я пообещал el777 все-таки дописать эту статью.

С фильтрами по ACL всё в целом ясно. Они действуют уже сейчас, и с ними с переменным успехом получается и не получается бороться (хотя существуют вполне себе пессимистические прогнозы). С DPI все интереснее.

Способы «определения» типа трафика у DPI можно разбить на две группы:

• Сигнатурный анализ. А именно, разбирание пакета «по косточкам», сопоставляя заголовки и структуру с образцами, и таким образом определение его предназначения. Таким образом детектируются многие туннели, например OpenVPN, L2TP/IPSec, SOCKS, и др.
• Предварительный анализ паттернов обмена трафиком, например, соотношения входящего/исходящего потока, периодичность запросов-ответов и другие критерии позволят отделить «настоящий трафик» какого-то протокола и туннель, лишь маскирующийся под него.

Можно разбить трафик на несколько групп и предположить, что будут делать с каждой из них.

1. «Явные» VPN, туннели и прокси (OpenVPN, L2TP/IPSec, SOCKS, и др.) Обычные VPN и туннели вполне могут блокироваться автоматически, как, например, это происходит в Китае и Венесуэле. Если каким-то организациям или компаниям оно нужно для работы — пусть регистрируются и сертифицируются, о чем вполне конкретно говорит российский закон, упомянутый выше. С прокси все еще проще — что HTTP, что SOCKS передают адреса и содержимое в открытом виде, что вообще не создает никаких проблем для выборочного «резания» запросов и прослушки передаваемой информацией.
2. Технологии «двойного назначения», например, SSH. Через небольшое время после установления сессии, скорость режется до черепашьей, так, что в консоли работать еще хоть как-то можно, а вот серфить и качать что-либо уже нет. То, что это создает проблемы при обычной работе, никого не волнует (что не раз нам демонстрировал РКН за недавнее время).
3. Узкоспецифические протоколы, типа месседжеров, игровых клиентов, и т.д.
4. Соединения, тип которых определить не удается.

Для пунктов 3 и 4 вполне возможны «белые списки» (в которые, например, заносятся подсети официальных игровых серверов или «правильных» месседжеров, и всего того, что владельцы серверов пожелают задекларировать и оформить как надо, чтобы их не трогали, по аналогии с теми, что уже сейчас есть у РКН для доменов и IP-адресов). А тех, кого в этих списках нет, ждет та же участь, что и п.1 или п.2, правда вполне возможна не тупая блокировка или обрезание скорости, а предварительно упомянутый выше анализ паттернов обмена в целях определения, является ли трафик «чистым» или «подозрительным».

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

Про разные ICMP и DNS туннели можно даже не вспоминать — большой объем трафика «куда не надо» по ним тоже автоматически вызывает подозрения.

5. TLS и SSL, HTTPS. Резать подчистую невозможно, поскольку это автоматически означает блокировку всего Интернета. Анализ паттернов не имеет смысла, поскольку веб-серфинг — как раз-таки и есть основное предназначение использование HTTPS. Из всего вышеперечисленного, SSL/TLS на 443 порту выглядит самым «не подозрительным» и надежным вариантом. Следовательно, давайте и попробуем замаскироваться под него.

Маскируемся

Для рассмотрения было решено выбрать решения Streisand и SoftEther.

Streisand — целый набор различных сервисов: OpenConnect/AnyConnect, OpenVPN, stunnel, Shadowsocks, WireGuard. Все это ставится в автоматическом или полуавтоматическом режиме «под ключ», и на выходе пользователь получает сконфигурированный сервер, а также файлы и подробную документацию по настройке клиентов.

SoftEther — VPN-сервер, который может поднимать L2TP/IPsec, OpenVPN, SSTP, и другие протоколы, а также имеет свой собственный протокол «SSL-VPN», который, по заявлениям авторов, неотличим от обычного HTTPS-трафика.

Итак…

OpenConnect/AnyConnect. Опенсорсная реализация протокола AnyConnect SSL от Cisco. При установлении соединения видны не только пакеты TLS (TCP), но и DTLS (UDP). DTLS в принципе тоже много где используется «в мирных целях», но это уже совсем не похоже на «обычный HTTPS». Впрочем, если порезать UDP-трафик на фаерволе, то AnyConnect сразу переключается обратно на TCP и со стороны выглядит, опять же, целиком и полностью как обычный TLS, и даже аутентификация внутри зашифрованного тоннеля проходит почти как в HTTP.

Shadowsocks. Шифрованный SOCKS-прокси. Судя по всему, при желании может быть детектирован, однако существуют плагины, маскирующие его под «чистый HTTPS». Так же есть плагин для работы через websockets, но об этом чуть позже.

WireGuard. Судя по описанию, имеет хорошо закрученное шифрование и механизм установки сессии, но весь обмен происходит по UDP. Wireshark определяет тип пакетов как нечто совсем невнятное, а какое мнение обо всем происходящем сложится у стороннего DPI — очень и очень большой вопрос. Upd: Новые версии определяют Wireguard однозначно как Wireguard, так что ответ на вопрос очевиден.

obfs3, obfs4. Обфуцируют пакеты так, что со стороны они выглядят абсолютно случайным набором значений. То есть попадают под п.4 из списка выше.

SoftEther. Выглядит как HTTPS, но с одним подвохом. Кроме непосредственно TLS over TCP активно шлет пачками UDP-пакеты. Как удалось выяснить в документации, UDP может использоваться для ускорения передачи данных в том случае, когда он не зарезан на фаерволе. Данный функционал отключается в конфигурации, и после его отключения все становится как надо.

SSTP. VPN-прокотол от компании Microsoft. Нативно поддерживается в Windows, вспомогательным софтом в GNU/Linux. Со стороны выглядит как HTTPS, и Wireshark это вполне подтверждает.

Но это еще не все

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

Следовательно, нам необходимо чтобы по 443 порту у нас отвечал самый обычный и порядочный веб-сервер. И вот тут встает интересная проблема.

Ни у одного из вышеперечисленных сервисов в основной документации не нашлось описания рабочего механизма port sharing’а. Вариант с SSLH не подходит, хотя бы потому, что sslh не способен разделить трафик между HTTPS и вышеуказанными сервисами. Как минимум, потому что если тип трафика без полной расшифровки смог отличить sslh — то сможет и DPI.

Большинство манов, наподобие этого, предлагают использовать Server Name Indication (SNI) — расширение TLS, позволяющее указывать имя хоста, и потом с помощью HAProxy, sniproxy и других тулов раскидывать подключения по сервисам. Проблема в том, что в современных реализациях TLS указанное при использовании SNI имя хоста передается plain text’ом, то есть в незашифрованном виде, и, следовательно, тоже может быть подсмотрено и использовано в дальнейшем.

Поэтому, будем импровизировать, и тут мне на ум пришли два варианта.

Port knocking

Port knocking как раз предназначен для активации «скрытых сервисов» на сервере. Например, подобным образом часто закрывают «наружу» порт, на котором висит SSH-демон, чтобы избежать брутфорса и использования 0-day уязвимостей. В классическом варианте (см. например реализацию демона knockd) под нокингом обычно понимают попытки установки соединения или посылку пакетов на определенные порты хоста в определенной последовательности, в результате чего демон вас «опознает» как своего, и активирует правило фаерволла, открывающее доступ на определенный порт только с вашего IP.

В нашем же случае, этот вариант не совсем приемлем. Во-первых, сами «нестандартные» порты могут быть заблокированы где-то по пути, а во-вторых, сама процедура при анализе со стороны может выглядеть подозрительно. Раз уж мы маскируемся под HTTPS, то и «стучаться» нужно по HTTPS.

Как ни удивительно, но HTTP/HTTPS нокеров с требуемой функциональностью не нашлось, и поэтому на свет родился нокер с романтичным названием Labean (гусары, молчать!).

Дано: наш сервер, на котором на 443 порту крутится Nginx c корректно настроенными сертификатами и выдает какой-нибудь вполне безобидный контент, например, GIF’ки с котиками, ISO-образы дистрибутивов GNU/Linux, или зеркало Википедии и библиотеки Мошкова.

При этом в конфиге Nginx затаились строки вида

 location ~ ^/somesecret/(.*) {
    auth_basic      "Administrator Login";
    auth_basic_user_file  /var/www/.htpasswd;
    proxy_set_header  X-Real-IP  $remote_addr;
    proxy_pass http://127.0.0.1:8080/$1;
  }

Когда мы хотим подключиться к скрытому сервису, мы переходим браузером или делаем запрос CURL’ом по адресу вида
https://ourserver.org/somesecret/vpn/on
проходим стандартную авторизацию, после чего нокер, получив и обработав наш запрос, выполнит команду на открытие доступа к скрытому сервису для нашего IP-адреса, например что-то вроде
iptables -t nat -A PREROUTING -p tcp -s {clientIP} --dport 443 -j REDIRECT --to-port 4443
после чего мы поднимаем туннель.

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

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

Таким образом можно сконфигурировать даже несколько разных сервисов, в том числе используя IPv6 (v6-адреса в заголовке типа X-Real-IP также поддерживаются).

Нокер написан на Go, не требует внешних зависимостей, прост как топор, и вполне себе работает. Исходники, подробное описание и примеры конфига nginx и init-скриптов можно найти на Github:
https://github.com/uprt/labean

Websockets

Вторая идея озарила еще более неожиданно: лучшее средство замаскировать туннель внутри HTTPS — использовать общепринятые стандартные инструменты. Современные Web-технологии давно уже содержат решение для установления связи поверх TCP между браузером и сервером, и имя ему Websocket (RFC 6455). Клиент формирует особый HTTP-запрос, на который сервер отвечает определенным образом, и после небольшого хендшейка мы можем начинать передачу данных по этому же TCP-соединению. Со стороны, соответственно, все выглядит в точности как обычный HTTPS и не требуется установки никаких дополнительных соединений.

Еще одним существенным преимуществом варианта с WS является то, что веб-сокеты — стандартная и распространенная технология, и они поддерживаются многими CDN, например, Cloudflare даже на бесплатном тарифе. Таким образом, это дает нам возможность повысить надежность нашей схемы: при блокировке по IP вашего CDN/proxy сервера вы сможете все равно подключиться к нему через CDN, либо же наоборот по умолчанию работать с этим вашим VPN/proxy сервером через CDN, скрывая его реальный адрес от сторонних наблюдателей.

Реализаций WS-туннелей существует несколько (есть даже вариант на Haskell), я для теста взял wstunnel, сделанный на nodejs и не прогадал, все завелось легко и с первого раза.

Лишь один нюанс был не прояснен в документации. Для запуска клиента предлагается указывать просто wss://-адрес, типа

wstunnel -t 33 wss://server:443

В нашем же случае, необходимо «отделить» ws-подключения к серверу туннелирования от запросов «обычного» сайта. Изучив исходники wstunnel, я пришел к выводу, что ничего не помешает удлинить URI после имени хоста каким-нибудь уникальным идентификатором:

wstunnel -t 33 wss://ourserver.org:443/hiddenws/

и оказался прав: все заработало с первого раза

Снова рассмотрим наш сервер, на котором на 443 порту запущен Nginx c каким-нибудь безобидным сайтом.

В конфиг нужно добавить proxy-проброс для нашего Websockets-туннеля:

location /hiddenws {
    proxy_pass http://127.0.0.1:8081;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "Upgrade";
  }

После чего мы можем тайным образом поднимать наш websockets-туннель. Поверх туннеля можно пустить подключение к обычному SOCKS-прокси (например, Dante), или OpenVPN, хотя, как по мне, это уже будет избыточно.
Про selinux
Если у вас RHEL подобный дистрибутив, и включен SELinux, и в логах nginx видны ошибки типа
2018/07/05 13:28:03 [crit] 7724#0: *11 connect() to 127.0.0.1:8081 failed (13: Permission denied) while connecting to upstream, client: IP_ADDRES, server: _, request: «GET /hiddenws/?dst=localhost:22 HTTP/1.1», upstream: «127.0.0.1:8081/hiddenws/?dst=localhost:22»,

то вам нужно разрешить демону подключаться к необходимому порту:

semanage port -a -t http_port_t -p tcp 22
semanage port -m -t http_port_t -p tcp 22
semanage port -a -t http_port_t -p tcp 8081

Спасибо Renatk за то что обратил внимание и предложил решение.

Единственный минус такого подхода — кроме непосредственно SOCKS- или VPN-клиента на устройстве также нужно иметь клиент wstunnel, что может быть сложным в случае использования смартфона или другого «недесктопного» устройства.

Кроме того, существует плагин v2ray для shadowcocks, позволяющий использовать websockets как транспорт для shadowsocks. Найти его можно здесь: https://github.com/shadowsocks/v2ray-plugin

Несколько советов

— Установите на VPN-сервере какое-нибудь стандартное значение MTU, например 1400;
— Назначьте вашему VPN-серверу 2 IP-адреса. На один он будет принимать подключения к VPN/прокси, а с другого будет уходить исходящий трафик;
— Для «выходного» IP-адреса закройте все порты, отключите ответ на ICMP ping;
— Пропишите для вашего сервера какое-нибудь безобидное reverse DNS имя, похожее на пул доступа интернет-провайдера, например, gateway-001.somehomeisp.net;
— Для резолва доменов клиентами вашего VPN/прокси используйте DNS-сервера проекта OpenNIC;
Все эти меры помогут пресечь выявление туннелей недобросовестными ресурсами (подробнее здесь).

Вместо заключения

Как на самом деле будет развиваться социально-техническое противостояние, мы знать не можем — только предполагать. Воплотятся ли в жизнь предположения, изложенные в статье, не воплотятся — узнаем со временем, как и о том, что будет дальше. Да, маскировка под HTTPS тоже не панацея от всего — например, делать это может быть опасно, если будут введены какие-либо реальные наказания за «использование несертифицированных средств шифрования»/ознакомление с заблокированными ресурсами/etc., или бесполезно, если всех обяжут устанавливать некий «сертификат безопасности», как это некоторое время назад хотели сделать в Казахстане.

Пока еще, к счастью, ни до того, ни до другого не дошло ни в одном из известных нам государств, и если оно случится — это знак, что пора эвакуироваться, причем не из страны, а с планеты.

Берегите себя.

Прокладываем L2 туннели в OpenVPN / Блог компании RUVDS.com / Хабр

Недавно меня попросили разобраться в настройке L2 туннеля для моста между двумя удалёнными локальными сетями, и я был поражён, насколько мало удобных решений мне удалось найти. Раньше я не интересовался этой темой и наивно полагал, что любой адекватный VPN-протокол умеет ловить широковещательные пакеты и пересылать их по обычному L3 туннелю. К сожалению, доступных «из коробки» универсальных решений нет. Есть несколько протоколов и инструментов для них, большинство из которых работает в очень ограниченных условиях или вовсе объявлено deprecated. Самым приятным вариантом я поделюсь дальше.

Почему именно L2?

Этим вопросом я задался в первую очередь: я довольно редко работаю с сетевой периферией, и мне казалось что довольно давно уже всё оборудование умеет ходить по L3. Как бы не так: кому-то нужен доступ к офисным принтерам, кому-то к видеорегистраторам, а кто-то просто хочет зарубиться с другом в LAN-дуэли — не выходя из дома, разумеется. Также очень привлекательной выглядит идея общих/сетевых папок в офисе, доступных из дома, особенно в период повальной удалёнки.

При этом среди разработчиков VPN-клиентов L2-бриджи почему-то считаются чем-то вроде странного каприза одного-двух процентов пользователей, который по большому счёту никому не нужен. Совсем иначе обстоят дела в промышленных сетях, где много устаревшего или плохо совместимого оборудования, и концепция L2VPN (представленная кучей других аббревиатур) реализована на уровне сети и оборудования провайдера.

Технологии

Их много, и они все работают со странностями и ограничениями:

• Например, протокол Layer 2 Tunneling Protocol (L2TP) должен, судя по названию, обеспечивать поддержку OSI L2 и в том числе проброс broadcast’a. Но нет, общепринятая связка L2TP + IPsec не позволяет бриджевать сети на уровне L2!
• PPTP — стал мемом из-за крупных уязвимостей, сейчас кое-как починен, но к L2 уже не имеет отношения.
• MPLS — жутко запутанный «промышленный» протокол на основе меток. Изучить его сложно, а поднять можно только на специализированном железе или RouterOS (с ограничениями, куда ж без них).
• PPPoE и феерический PPPoEoE тоже работают, но на проприетарных железках. Режим PPPoE вообще есть на многих роутерах, но как его правильно готовить известно по большей части только на фирменном оборудовании типа Cisco.
• EoIP должен быть стать тем самым L2VPN made right, но он тоже работает только на микротиках, что существенно сужает круг применения. Как и PPTP, используя GRE, не проходит через NAT.

И тут я с удивлением обнаружил, что настоящий Ethernet Bridging умеет… OpenVPN!

Мы часто пользуемся личным или рабочим VPNом, у многих он вообще включён на постоянной основе для обхода блокировок (хотя эта тенденция идёт на спад после снятия блокировки Telegram). В своих рабочих задачах я тоже постоянно пользуюсь удаленными хостами для разработки, и почти всегда использую OpenVPN. Долгое время я не понимал, зачем нужна связка OpenVPN Access Server + OpenVPN Connect на клиенте. Для моих задач мне всегда хватало классической версии с ручной правкой конфигов, и выделенные админки и GUI казались неуместными в стройном тонком клиенте. Но оказалось, что для настройки бриджа интерфейс гораздо удобнее чем простыни конфигов в терминале, хотя и с ним не всё идеально.

Настройка

Дело в том, что Access Server (AS) выходил как платный и довольно дорогой продукт, поэтому в него старательно напихали всевозможных плюшек, лишь бы купили. Таким образом в веб-админке появился подпункт меню, позволяющий выбрать режим сети (L2 bridging/L3 routing), а через какое-то время тихонько был оттуда выпилен по всё той же причине «это никому не нужно». Тем не менее, сам функционал бриджинга и соответствующие скрипты не удаляли и их по-прежнему можно настроить.

Установка

Нам потребуется сервер или виртуальная машина. Образ для неё находится на странице загрузки, а мы будем дальше разбирать кейс с установкой на сервер под Ubuntu 18.04:

apt update && apt -y install ca-certificates wget net-tools gnupg
wget -qO - https://as-repository.openvpn.net/as-repo-public.gpg | apt-key add -
echo "deb http://as-repository.openvpn.net/as/debian bionic main">/etc/apt/sources.list.d/openvpn-as-repo.list
apt update && apt -y install openvpn-as

После установки сервер поднимется самостоятельно, вы увидите такое сообщение:

+++++++++++++++++++++++++++++++++++++++++++++++
Access Server 2.8.4 has been successfully installed in /usr/local/openvpn_as
Configuration log file has been written to /usr/local/openvpn_as/init.log

Access Server Web UIs are available here:
Admin  UI: https://185.209.31.165:943/admin
Client UI: https://185.209.31.165:943/
+++++++++++++++++++++++++++++++++++++++++++++++

Сразу нужно указать пароль для админской учётки:

passwd openvpn

Затем можно открывать админку в браузере (на :943/admin, как указано выше), логиниться под пользователем openvpn с указанным паролем и настраивать сервер.

AS бесплатна для использования двумя пользователями, дальше можно добавлять только за $18/месяц за одного пользователя, так что лучше сразу спроектировать свои процессы под использование туннеля двумя клиентами.

Возвращаем бриджинг

cd /usr/local/openvpn_as/scripts
./sacli --key "von.general.osi_layer" --value "2" ConfigPut
./sacli start

Если всё прошло успешно, в выведенном json’е будет такое:

{
 "errors": {},
 "last_restarted": "Thu Jul  2 00:07:37 2020",
 "service_status": {
   "api": "on",
   "auth": "on",
   "bridge": "on",
        ...
    }
}

В админке статус «OSI Layer: 3 (routing/NAT)» поменяется на «2 (bridging)»

NB: в последних версиях может оставаться информация о L3 при включённом bridge. Почему — не разбирался, безопасные в этом плане версии около 2.4

Собственно на этом ноу-хау заканчивается, дальше вам нужно просто настроить под себя сервер, завести второго пользователя через тот же веб-интерфейс и залогиниться на пользовательскую страницу на 943 порту (без /admin). Там будут ссылки на скачивание клиентов OpenVPN Connect под все платформы с запечённым конфигом для подключения (кроме мобильных приложений, там придется вбить адрес вручную, а дальше всё само установится).

После успешного подключения и бриджевания клиентов, будет доступен L2-туннель с TCP/UDP трафиком. Клиенты могут выступать натом для внутренней сети, это всё тоже настраивается в админке.

VPN-туннель домой. Настройка клиентов iOS и Android.

Я хотел получить доступ к домашней сети из любой точки мира. Например, с работы или из кино. Чтобы забрать какой-то файл, который я оставил на домашнем компьютере, или поставить кино на закачку, или включить вебкамеру и посмотреть, не зашли ли ко мне воры! В TomatoUSB, который я накатил на роутер, как раз есть всё необходимое.

Сначала надо либо арендовать статический IP у вашего провайдера, либо настроить Dynamic DNS, чтобы когда вы не дома, вы всегда могли знать IP-адрес вашего роутера.

Настройки VPN-сервера находятся в разделе «VPN Tunneling → OpenVPN Server». Сначала нагенерим ключи. На роутере нет интерфейса для генерации ключей, будем генерировать на линуксовой или маковой машине. Генерировать надо там, куда не пройдёт злоумышленник, и там, где вы эти ключи не потеряете.

Скачиваем easy-rsa. Клонируем или качаем архив в разделе «Releases». И заходим в easy-rsa/easyrsa3.

Создаём инфраструктуру ключей:

./easyrsa init-pki

Создаём удостоверяющий центр:

./easyrsa build-ca

Команда спросит пароль, вы будете его вводить каждый раз при создании ключей для нового устройства, так что сделайте его надёжным и не забудьте. Ещё спросит «Common Name» — это имя удостоверяющего центра, и для домашней сети можно ввести что угодно.

Эта команда нагенерит два файла: pki/ca.crt — сертификат, который нужно будет закинуть в роутер и на каждый клиент; и pki/private/ca.key — приватный ключ удостоверяющего центра, которым и будут подписываться ключи для клиентов. Пароль, который вы вводили — от этого ключа.

Теперь сгенерируем ключи для роутера:

./easyrsa build-server-full router nopass

Команда спросит пароль, который вы создали при генерации удостоверяющего центра. И создаст файлы: pki/private/router.key — приватный ключ сервера; и pki/issued/router.crt — сертификат сервера.

Теперь сгенерируем файл Диффи-Хелмана:

./easyrsa gen-dh

Пока команда работает, можно попить чай. Теперь зальём все ключи на сервер. В «VPN Tunneling → OpenVPN Server» на вкладке «Keys» заливаем:

• в поле «Certificate Authority» содержимое файла pki/ca.crt;
• в поле «Server Certificate» содержимое pki/issued/router.crt;
• в поле «Server Key» — pki/private/router.key;
• в «Diffie Hellman parameters» — pki/dh.pem.

Не забудьте нажать кнопку «Save» внизу.

На вкладке «Basic» в этом разделе всё нормально, я ещё поставил галку «Start with WAN», чтобы VPN-сервер работал всегда, когда есть интернет.

На вкладке «Advanced» ставлю галку «Respond to DNS», чтобы из VPN можно было ходить по локальным адресам типа mediaserver.lan, как я писал в предыдущей статье. И под ней появляется галка «Advertise DNS to clients», чтобы клиент при подключении узнавал, что на роутере есть DNS-сервер, в который надо ходить.

Ещё в «Advanced» я ставлю «Manage Client-Specific Options», и появившуюся под ней «Allow Client ↔ Client» — чтобы VPN-клиенты могли между собой взаимодействовать.

Сохраняемся и нажимаем кнопку «Start Now».

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

Удобный способ:

./easyrsa build-client-full lenin nopass

Это значит «сделай всё для клиента по имени lenin и чтобы без пароля». Чтобы с паролем, надо убрать nopass (будет спрашивать при подключении). Получится два файла: pki/private/lenin.key и pki/issued/lenin.crt — ключ и сертификат соответственно.

Правильный способ описан в доке easy-rsa. В общем, генерируете ключи для всех клиентов. Но лучше сначала для одного сделать и проверить, всё ли вы сделали правильно.

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

Для того, чтобы все эти файлы притащить на клиент, придумали формат .ovpn. Там в одном файле и настройки, и ключ, и сертификаты. Формат его такой:

Настройки списком

<ca>
сертификат удостоверяющего центра
</ca>
<cert>
сертификат клиента
</cert>
<key>
ключ клиента
</key>

Я написал скрипт, который генерирует .ovpn файл из шаблона конфигурации. Там, где у вас удостоверяющий центр, создайте шаблон template.ovpn примерно такой:

client
dev tun
remote example.com # Замените этот адрес на ваш IP или DDNS-домен
resolv-retry infinite
nobind
persist-key
persist-tun
verb 1
keepalive 10 120
port 1194
proto udp
cipher BF-CBC
comp-lzo
remote-cert-tls server
redirect-gateway
key-direction 1
${ca}
${cert}
${key}

В директории easy-rsa/easyrsa3, в которой вы генерировали ключи и сертификаты, выполните:

./ovpn_maker.sh template.ovpn lenin > lenin.ovpn

Это значит «сгенерируй-ка мне файл lenin.ovpn с ключами для клиента lenin и настройками из template.ovpn». Полученный файл надо закинуть на устройство.

1. Поставьте OpenVPN Connect.
2. Скиньте файл .ovpn на телефон.
3. Откройте OpenVPN Connect, нажмите на кнопку ⋮ в правом верхнем углу и выберите «Import → Import Profile from SD card».
4. Найдите и импортируйте ваш файл.

Теперь переключитесь на другой WiFi или на мобильный интернет, чтобы проверить подключение. Жмите «Connect» и смотрите, что всё работает. Попробуйте зайти на ваш роутер и на другие сервера вашей домашней сети. Если вы настраивали VPN так, чтобы весь трафик шёл через VPN, то и это проверьте. Например, зайдите на Яндекс.Интернетометр и убедитесь, что ваш IP совпадает с домашним.

Если что-то пошло не так, то можно нажать на ⋮ и выбрать там «Show log file». И разбираться, почему не работает.

Иконку для подключения VPN-туннеля можно вывести на домашний экран. Для этого в приложении нажмите «⋮ → Add Shortcut». Подключения можно переименовывать.

1. Установите OpenVPN Connect. Теперь надо скинуть .ovpn в телефон.
2. Подключите телефон к компу и откройте iTunes.
3. Выберите там ваш телефон, в левой колонке выберите Apps, и прокрутите вниз до секции «File Sharing».
4. В этой секции выберите OpenVPN, жмите кнопку «Add» и выбирайте ваш файл.
5. Открывайте на телефоне OpenVPN Connect.
6. Там увидите ваш файл, он будет называться типа «адрес-сервера/имя-клиенте». Жмите под ним зелёный плюс.

Теперь так же подключитесь к другой сети (соседский WiFi или мобильный интернет), и попробуйте подключить VPN. Проверьте, что можете открыть ресурсы домашней сети. За кнопкой со статусом соединения (Connecting / Connected) скрывается лог, в который надо смотреть в случае проблем.

Подключения тоже можно переименовывать. И включать их можно прямо в настройках айфона: «Settings → VPN». Всё описанное справедливо и для айпада.

Если вы хотите настроить VPN более тонко, и подробнее узнать про ключи и сертификаты, то почитайте большое руководство по установке и настройке OpenVPN на хабре.

Поддержка — Построение динамического VPN туннеля

Описание

Если возникает необходимость связать несколько офисов, например в разных городах, можно использовать туннель через публичную сеть.
Предположим, у вас есть выход в Интернет на обеих ваших точках. Достаточно иметь оборудование для построения и публичные ip адреса с обеих сторон.
Туннель VPN создается по сети Интернет и шифруется с использованием ряда передовых алгоритмов шифрования для обеспечения конфиденциальности передаваемых данных между двумя узлами.
Мы будем рассматривать построение VPN GRE туннеля на оборудовании cisco.
В данном примере мы предположим, что один Cisco маршрутизаторы имеет статический публичный IP-адрес, а второй динамический IP-адрес
В этом случае используется технология DMVPN (Dymamic Multipoint VPN).
К сожалению, она не имеет аналогов и может быть использована только между роутерами cisco.

Настройка

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

Конфигурация на центральном узле

interface Tunnel1
 ip address 10.136.17.1 255.255.255.0
 ip nhrp map multicast dynamic
 ip nhrp network-id 99
 ip nhrp holdtime 300
 ip nhrp authentication dmvpn
 tunnel source Dialer1
 tunnel mode gre multipoint

ip address 10.136.17.1 255.255.255.0 — ip адрес из приват сети, по которой будут соединяться хаб и клиенты.
ip nhrp map multicast dynamic— динамическое изучение данных NHRP от клиентов. клиенты могут иметь динамические ip адреса.
ip nhrp network-id 99 — просто идентификатор nhrp, необязательно может быть одинаковым на всех узлах.
ip nhrp holdtime 300— задает время, которое динамическая запись хранится в базе. По происшествию данного времени запись должна быть обновлена.
ip nhrp authentication dmvpn — необязательная опция, dmvpn — пароль для установления соединения по протоколу nhrp
tunnel source Dialer1 — привязка туннеля к физическому интерфейсу, который смотрит в интернет.
tunnel mode gre multipoint — Туннель на центральном узле будет терминировать все туннели от удалённых точек. То есть он будет точка-многоточка (Point-to-MultiPoint).

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

interface Tunnel1
 ip address 10.136.17.36 255.255.255.0
 ip nhrp map multicast dynamic
 ip nhrp map 10.136.17.1 213.184.244.97
 ip nhrp map multicast 213.184.244.97
 ip nhrp network-id 99
 ip nhrp holdtime 300
 ip nhrp nhs 10.136.17.1
 ip nhrp authentication dmvpn
 tunnel source Dialer1
 tunnel mode gre multipoint

ip address 10.136.17.36 255.255.255.0 — ip адрес из приват сети, по которой будут соединяться хаб и клиенты.
ip nhrp map 10.136.17.1 200.0.0.1 — Статическое соотношение внутреннего и внешнего адресов центрального узла.
ip nhrp map multicast 200.0.0.1 — Мультикастовый трафик должен получать хаб.
ip nhrp nhs 10.136.17.1 — Статически настроенный адрес NHRP сервера — центрального узла.

остальные параметры аналогичны параметрам на центральном узле.

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

На данном этапе мы уже можем посмотреть состояние туннелей.

sh interfaces Tunnel 1
Tunnel1 is up, line protocol is up
  Hardware is Tunnel
  Internet address is 10.136.17.1/24
  MTU 1514 bytes, BW 128 Kbit/sec, DLY 10000 usec,
     reliability 255/255, txload 21/255, rxload 39/255
  Encapsulation TUNNEL, loopback not set
  Keepalive not set
  Tunnel source 200.0.0.1 (Dialer1), destination UNKNOWN
  Tunnel protocol/transport multi-GRE/IP

#ping 10.136.17.36
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.136.17.36, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 48/51/64 ms

Эта команда показывает таблицу nhrp со стороны центрального узла

10.136.17.36/32 via 10.136.17.36, Tunnel1 created 2d20h, expire 00:04:56
  Type: dynamic, Flags: unique registered used
  NBMA address: 111.111.111.111

со стороны филиала

#sh ip nhrp
10.136.17.1/32 via 10.136.17.1, Tunnel1 created 2d21h, never expire
  Type: static, Flags: authoritative used
  NBMA address: 200.0.0.1

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

Прописываем на обоих маршрутизаторах

router eigrp 511
 passive-interface default
 no passive-interface Tunnel1
 network 10.136.0.0 0.0.255.255

router eigrp 511 — router id
network 10.136.0.0 0.0.255.255 — определяем анонсируемые сети
passive-interface default — по умолчанию ни один интерфейс ни участвует в маршрутизации eigrp
no passive-interface Tunnel1 — в маршрутизации участвуют туннельные интерфейсы

роутинг eigrp на центральном узле
об этих сетях нам рассказывает router eigrp удаленного узла

sh ip route eigrp
D       10.136.36.128/29 [90/20281600] via 10.136.17.36, 00:39:38, Tunnel1
D       10.136.36.148/30 [90/20281600] via 10.136.17.36, 00:39:38, Tunnel1

роутинг eigrp на удаленном узле
об этих сетях нам рассказывает router eigrp центрального узла

sh ip route eigrp
 10.136.46.0/30 [90/20537600] via 10.136.17.1, 00:39:48, Tunnel1
 10.136.51.0/30 [90/20537600] via 10.136.17.1, 2d05h, Tunnel1

Теперь пинг между узлами будет проходить.

mysql — проблемы с туннелем VPN OpenSWAN между узлами с AWS

Переполнение стека

1. Около

2. Продукты

3. Для команд

1. Переполнение стека
   Общественные вопросы и ответы

2. Переполнение стека для команд
   Где разработчики и технологи делятся частными знаниями с коллегами

3. Вакансии
   Программирование и связанные с ним технические возможности карьерного роста

4. Талант
   Нанимайте технических специалистов и создавайте свой бренд работодателя

5. Реклама
   Обратитесь к разработчикам и технологам со всего мира

6. О компании

Загрузка…

2. Авторизоваться
   зарегистрироваться

3. текущее сообщество
   

.

Устранение неполадок VPN-туннеля

Я не могу установить или поддерживать соединение виртуальной частной сети (VPN) с моим Amazon Virtual Private Cloud (Amazon VPC).

Проблемы с установкой VPN-соединения могут возникать из-за конфигурации:

• Обмен ключами в Интернете (IKE)
• Безопасность интернет-протокола (IPsec)

Проблемы с поддержанием VPN-соединения могут возникать из-за конфигурации:

• Списки управления доступом к сети (сетевые ACL)
• Правила группы безопасности VPC
• Таблицы сетевой маршрутизации экземпляра Amazon Elastic Compute Cloud (Amazon EC2)
• Брандмауэры инстансов Amazon EC2
• Виртуальные частные шлюзы
• Резервирование VPN-туннеля

Проблемы с установкой VPN-соединения

Проблемы с поддержанием VPN-соединения

Если вы успешно установили оба VPN-туннеля, но по-прежнему испытываете проблемы с подключением, то:

1. Проверьте сетевые ACL в вашем VPC, которые не позволяют подключенной VPN устанавливать соединение.
2. Убедитесь, что правила группы безопасности, назначенные экземплярам EC2 в вашем VPC, разрешают соответствующий доступ. Обязательно разрешите входящий доступ по SSH, RDP и ICMP. Дополнительные сведения см. В разделах Группы безопасности Amazon EC2 для экземпляров Linux или Группы безопасности Amazon EC2 для экземпляров Windows.
3. Убедитесь, что таблицы маршрутизации, подключенные к вашему VPC, правильно настроены.
4. Проверьте наличие брандмауэров уровня операционной системы (уровня ОС), которые блокируют трафик к экземплярам EC2 внутри вашего VPC.
   Для экземпляров EC2 Windows запустите WF.msc в командной строке.
   Для экземпляров EC2 Linux запустите iptables в сеансе терминала с соответствующими аргументами. Для получения более подробной информации запустите man iptables .

Примечание. AWS принимает только одну пару ассоциаций безопасности для VPN-соединения (одну входящую и одну исходящую). Если ваш клиентский шлюз использует VPN на основе политик, настройте внутреннюю сеть в качестве адреса источника (0.0.0.0 / 0) и подсеть VPC в качестве адреса назначения. Эта конфигурация позволяет трафику к VPC проходить через VPN без создания дополнительных сопоставлений безопасности.

VPN-туннель возникает, когда трафик создается со стороны клиентского шлюза VPN-соединения. Сторона виртуального частного шлюза не является инициатором. Если ваше соединение VPN испытывает период простоя (обычно 10 секунд, в зависимости от конфигурации клиентского шлюза), туннель может выйти из строя.Чтобы предотвратить эту проблему, используйте инструмент сетевого мониторинга, чтобы сгенерировать keepalive ping. Например, для устройств Cisco ASA включите мониторинг SLA.

Если вы исключите конфигурацию VPC и подключение экземпляра EC2 как возможные основные причины, то:

1. Откройте сеанс терминала (Linux) или командную строку (Windows).
2. Запустите утилиту traceroute (Linux) или tracert (Windows) из внутренней сети в экземпляр EC2 в VPC, к которому подключен ваш VPN.
3. Если вывод останавливается на IP-адресе, связанном с вашей внутренней сетью, убедитесь, что путь маршрутизации к вашему граничному устройству VPN правильный.
4. Если выходные данные достигают устройства клиентского шлюза, но не экземпляра EC2, проверьте настройки устройства клиентского шлюза VPN. Убедитесь, что ваша конфигурация VPN, политики и настройки преобразования сетевых адресов (NAT) верны. Также убедитесь, что любые восходящие устройства разрешают поток трафика.

Если протокол пограничного шлюза (BGP), используемый в вашем VPN-туннеле, не работает, то:

1. Убедитесь, что вы определили номер автономной системы BGP (ASN) при создании клиентского шлюза.ASN клиентского шлюза включен в загружаемую конфигурацию VPN.
2. При необходимости обновите свой клиентский шлюз, указав правильный ASN. ASN должен соответствовать ASN, который вы указали при настройке VPN. ASN — это либо существующий ASN, назначенный вашей сети, либо частный ASN в диапазоне 64512–65534.
3. Убедитесь, что любые локальные конфигурации брандмауэра на вашем клиентском шлюзе позволяют трафику BGP проходить в AWS. Дополнительные сведения см. В руководствах по устранению неполадок для конкретных устройств.

Если возможно, используйте проверку избыточности VPN-туннеля AWS Trusted Advisor в своих действиях по мониторингу:

1. Войдите в консоль Trusted Advisor.
2. На панели навигации под Dashboard выберите Fault Tolerance .
3. На панели содержимого выберите VPN Tunnel Redundancy из списка Fault Tolerance Checks .
4. Выберите значок загрузки, чтобы загрузить результаты этой проверки.

Дальнейшее устранение неисправностей

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

• Контакт с административным доступом к локальному сетевому оборудованию и ресурсам VPC.
• Марка и модель физического устройства, которое вы используете для установки VPN-соединения, включая версию прошивки.
• Идентификаторы для вашего VPC (vpc-XXXXXXXX), виртуального частного шлюза (vgw-XXXXXXXX) и VPN (vpn-XXXXXXXX).
• Доступ к текущей конфигурации вашего устройства VPN и конфигурации, созданной консолью AWS при создании туннелей VPN.
• Подробная информация об истории подключений VPN
• IP-адрес экземпляра EC2 или другого ресурса внутри VPC для целей тестирования.
• Исходный IP-адрес локальной сети (LAN), из которой вы пытаетесь инициировать VPN-соединение.

.

Настройка туннелей GRE VPN точка-точка

Generic Routing Encapsulation ( GRE ) — это протокол туннелирования, разработанный Cisco, который позволяет инкапсулировать широкий спектр протоколов сетевого уровня внутри соединений точка-точка.

Туннель GRE используется, когда пакеты нужно отправить из одной сети в другую через Интернет или небезопасную сеть. С GRE виртуальный туннель создается между двумя конечными точками (маршрутизаторами Cisco), и пакеты отправляются через туннель GRE.

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

На схеме ниже показана процедура инкапсуляции простого незащищенного пакета GRE, когда он проходит через маршрутизатор и входит в туннельный интерфейс:

Хотя многие могут подумать, что туннель GRE IPSec между двумя маршрутизаторами похож на VPN IPSec между сайтами (шифрование), это не так.Основное отличие состоит в том, что туннели GRE позволяют многоадресным пакетам проходить через туннель, тогда как IPSec VPN не поддерживает многоадресные пакеты. В больших сетях, где необходимы протоколы маршрутизации, такие как OSPF, EIGRP, туннели GRE — ваш лучший выбор. По этой причине, плюс тот факт, что туннели GRE намного проще настроить, инженеры предпочитают использовать GRE, а не IPSec VPN.

В этой статье объясняется, как создавать простые (незащищенные) и безопасные (зашифрованные IPSec) туннели GRE между конечными точками.Мы объясним все необходимые шаги для создания и проверки туннеля GRE (незащищенного и защищенного) и настройки маршрутизации между двумя сетями.

Создание туннеля Cisco GRE

Туннель

GRE использует «туннельный» интерфейс — логический интерфейс, настроенный на маршрутизаторе с IP-адресом, где пакеты инкапсулируются и декапсулируются при входе в туннель GRE или выходе из него.

Первый шаг — создать наш туннельный интерфейс на R1:

R1 (config) # интерфейс Tunnel0

R1 (config-if) # IP-адрес 172.16.0.1 255.255.255.0

R1 (config-if) # IP MTU 1400

R1 (конфигурация-если) # IP TCP Adjust-MSS 1360

R1 (config-if) # источник туннеля 1.1.1.10

R1 (config-if) # пункт назначения туннеля 2.2.2.10

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

В нашем примере оба туннельных интерфейса являются частью сети 172.16.0.0/24 .

Поскольку GRE является протоколом инкапсуляции, мы устанавливаем максимальную единицу передачи (mtu) на 1400 байтов и максимальный размер сегмента (mss) на 1360 байтов. Поскольку большинство транспортных MTU составляют 1500 байтов, и у нас есть дополнительные накладные расходы из-за GRE, мы должны уменьшить MTU, чтобы учесть дополнительные накладные расходы. Установка 1400 является обычной практикой и гарантирует сведение к минимуму ненужной фрагментации пакетов.

В заключение мы определяем источник туннеля, который является публичным IP-адресом маршрутизатора R1, и пункт назначения — публичный IP-адрес R2

.

Как только мы завершим настройку R1, маршрутизатор подтвердит создание туннеля и сообщит о его статусе:

R1 #
* 4 мая 21:30: 22.971:% LINEPROTO-5-UPDOWN: Линейный протокол на интерфейсном туннеле , состояние изменено на вверх

Поскольку интерфейс туннеля 0 является логическим, он будет работать, даже если на другом конце не настроен или не подключен туннель GRE.

Затем мы должны создать интерфейс Tunnel 0 на R2:

R2 (config) # интерфейс Tunnel0

R2 (config-if) # IP-адрес 172.16.0.2 255.255.255.0

R2 (конфигурация-если) # IP MTU 1400

R2 (конфигурация-если) # IP TCP Adjust-MSS 1360

R2 (config-if) # источник туннеля 2.2.2.10

R2 (config-if) # пункт назначения туннеля 1.1.1.10

Интерфейс туннеля

R2 настроен с использованием соответствующего IP-адреса источника и назначения туннеля.Как и в случае с R1, маршрутизатор R2 сообщит нам, что интерфейс Tunnel0 включен:

R2 #
* 4 мая 21:32: 54.927:% LINEPROTO-5-UPDOWN: Линейный протокол на интерфейсном туннеле , состояние изменено на вверх

Маршрутизация сетей через туннель GRE

На этом этапе обе конечные точки туннеля готовы и могут «видеть» друг друга. Эхо icmp с одного конца подтвердит это:

R1 # пинг 172.16.0.2

Введите escape-последовательность для отмены.

Отправка 5 100-байтовых эхо-сообщений ICMP на 172.16.0.2, время ожидания составляет 2 секунды:

!!!!!

Уровень успеха составляет 100 процентов (5/5), мин. / Сред. / Макс. Туда-обратно = 1/2/4 мс

R1 #

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

R1 (конфигурация) # IP-маршрут 192.168.2.0 255.255.255.0 172.16.0.2

На R1 мы добавляем статический маршрут к удаленной сети 192.168.2.0 / 24 через 172.16.0.2, который является другим концом нашего туннеля GRE. Когда R1 получает пакет для сети 192.168.2.0, он теперь знает, что следующим переходом является 172.16.0.2, и поэтому отправит его через туннель.

Эту же конфигурацию необходимо повторить для R2:

R2 (конфигурация) # IP-маршрут 192.168.1.0 255.255.255.0 172.16.0.1

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

Защита туннеля GRE с помощью IPSec

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

Для этой цели мы используем IPSec для добавления уровня шифрования и защиты туннеля GRE. Это обеспечивает нам необходимое шифрование военного уровня и душевное спокойствие. В нашем примере ниже рассматривается режим туннеля GRE IPSec.

Режимы

GRE IPSec подробно описаны в наших статьях GRE и IPSec — GRE Over IPSec — Выбор и настройка Gre IPSec Tunnel или транспортного режима.

Настройка шифрования IPSec для туннеля GRE (GRE over IPSec)

Шифрование

IPSec включает два этапа для каждого маршрутизатора. Эти шаги:

(1) Настроить ISAKMP (ISAKMP Phase 1)

(2) Настроить IPSec (ISAKMP Phase 2)

Настроить ISAKMP (IKE) — (ISAKMP Phase 1)

IKE существует только для установления SA (Security Association) для IPsec. Прежде чем это сделать, IKE должен согласовать отношения SA (ISAKMP SA) с одноранговым узлом.

Для начала приступим к работе над R1.

Первый шаг — настроить политику ISAKMP Phase 1:

R1 (config) # политика крипто isakmp 1

R1 (config-isakmp) # encr 3des

R1 (config-isakmp) # хэш md5

R1 (config-isakmp) # предварительная проверка подлинности

R1 (config-isakmp) # группа 2

R1 (config-isakmp) # время жизни 86400

Приведенные выше команды определяют следующее (в указанном порядке):

3DES — метод шифрования, который будет использоваться на этапе 1.

MD5 — Алгоритм хеширования

Pre-share — использовать предварительный общий ключ в качестве метода аутентификации

Группа 2 — Используется группа Диффи-Хеллмана

86400 — Срок действия сеансового ключа. Выражается в килобайтах (после x-количества трафика измените ключ) или в секундах. Набор значений — это значение по умолчанию.

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

R1 (config) # крипто-ключ isakmp firewallcx адрес 2.2.2.10

Для предварительного общего ключа однорангового узла установлено значение firewallcx . Этот ключ будет использоваться для всех переговоров ISAKMP с партнером 2.2.2.10 (R2).

Создание преобразования IPSec (политика ISAKMP Phase 2)

Теперь нам нужно создать набор преобразований, используемый для защиты наших данных. Мы назвали это TS :

.

R1 (config) # набор преобразования крипто-ipsec TS esp-3des esp-md5-hmac
R1 (cfg-crypto-trans) # режим транспорта

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

— ESP-3DES — Метод шифрования

— MD5 — Алгоритм хеширования

— Установить IPSec на транспортный режим

Наконец, мы создаем профиль IPSec для соединения ранее определенной конфигурации ISAKMP и IPSec.Мы назвали наш профиль IPSec protect-gre :

.
R1 (конфигурация) # Профиль шифрования IPsec protect-gre

R1 (ipsec-profile) # установить время жизни ассоциации безопасности в секундах 86400

R1 (ipsec-profile) # набор преобразований набор TS

Мы готовы применить шифрование IPSec к туннельному интерфейсу:

R1 (config) # interface Tunnel 0
R1 (config-if) # Tunnel Protection Профиль ipsec protect-gre

Теперь пришло время применить ту же конфигурацию на R2:

.
R2 (config) # политика крипто isakmp 1

R2 (config-isakmp) # encr 3des

R2 (config-isakmp) # хэш md5

R2 (config-isakmp) # предварительная проверка подлинности

R2 (config-isakmp) # группа 2

R2 (config-isakmp) # время жизни 86400

R2 (config) # крипто-ключ isakmp firewallcx адрес 1.1.1.10

R2 (конфигурация) # набор преобразования крипто-ipsec TS esp-3des esp-md5-hmac

R2 (cfg-crypto-trans) # режим транспорта

R2 (конфигурация) # Профиль crypto ipsec protect-gre

R2 (ipsec-profile) # установить время жизни ассоциации безопасности в секундах 86400

R2 (ipsec-profile) # набор преобразований набор TS

R2 (config) # интерфейс Туннель 0

R2 (config-if) # защита туннеля Профиль ipsec protect-gre

Проверка GRE через туннель IPSec

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

R1 # пинг 192.168.2.1

Введите escape-последовательность для отмены.

Отправка 5 100-байтовых эхо-сообщений ICMP на адрес 192.168.2.1, таймаут 2 секунды:

!!!!!

Коэффициент успеха составляет 100 процентов (5/5), мин. / Сред. / Макс. Туда-обратно = 1/3/4 мс

Используя команду show crypto session , мы можем быстро проверить, что шифрование установлено и выполняет свою работу:

R1 # показать криптосессию

Текущее состояние криптосессии

Интерфейс: Tunnel0

Статус сеанса: UP-ACTIVE

Партнер: 2.2.2.10 порт 500

IKE SA: локальный 1.1.1.10/500 удаленный 2.2.2.10/500 Активный

IPSEC FLOW: разрешить 47 хост 1.1.1.10 хост 2.2.2.10

Активные SA: 2, происхождение: криптокарта

Вернуться в раздел маршрутизаторов Cisco

.

FMC VPN между сайтами

Последнее обновление: 5 октября 2018 г. в 9:35 (UTC)

Брандмауэры

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

В этой статье мы рассмотрим, как настроить VPN типа «сеть-сеть» через FMC.

Обратите внимание, это относится к управляющим устройствам FMC, на которых работает FTD. У обычных ASA с Firepower Services VPN не настроены в FMC.

Перед запуском

рекомендуется иметь представление о IPSec, особенно о фазах 1 и 2.

Основы IPSecASA VPN

Топологии

Первое, о чем нужно знать, — это поддерживаемые топологии. На выбор предлагается три типа топологии:

• От точки к точке — это простая топология между двумя конечными точками. В FMC необходимо определить узлы A и B
• Hub and Spoke — Группа лучевых сайтов, создающих туннели к центральному сайту
• Full Mesh — Группа многоточечных туннелей, где любое устройство может подключаться к любому другому

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

Любое устройство в топологии VPN, не управляемое FMC, называется устройством Extranet . Сюда входят устройства в вашей сети, которые не поддерживают защиту от угроз, устройства вне вашей сети (например, маршрутизатор в партнерской сети) и устройства защиты от угроз, управляемые другим сервером FMC.

Мы можем использовать FMC для отправки конфигурации VPN для удаления устройств FTD. Это возможно для устройств, управляемых в нашем FMC, или устройств, управляемых другим сервером FMC (например, удаленного офиса, управляемого другой командой).

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

Никакого специального лицензирования для VPN не требуется, пока активирован экспортных функций .

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

Политики IKE и предложения IPSec

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

Есть несколько предопределенных политик IKE, которые вы можете использовать или можете создать свои собственные:

1. Перейти на вкладку Объекты
2. Перейдите к VPN , затем к IKEv1 или IKEv2

Как показано ниже, вы можете выбрать алгоритмы, которые хотите использовать. То же самое относится к предложениям IPSec.

Топология

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

1. Перейти к устройствам -> VPN -> Site To Site
2. Нажмите Добавить VPN -> Устройство защиты от угроз огневой мощи
3. Введите имя топологии
4. Выберите тип топологии (в нашем случае от точки до )
5. Выберите версию IKE для использования (рекомендуется IKEv2)

Теперь нам нужно определить нашу первую конечную точку (узел A).

1. Убедитесь, что вы находитесь на вкладке Конечные точки
2. Рядом с узлом Node A нажмите зеленую кнопку Добавить
3. Выберите устройство защиты от угроз, которым управляет FMC, из списка
4. Выберите интерфейс, на котором будет установлена ​​VPN на
5. Если на этом интерфейсе более одного IP-адреса, выберите тот, который будет использоваться
6. Если это частный IP-адрес (не маршрутизируемый через Интернет), установите флажок Этот IP-адрес является частным и введите соответствующий общедоступный IP-адрес
7. Выберите тип подключения
   • Двунаправленный — любой узел может согласовывать VPN
   • Только ответ — Локальный узел будет отвечать, когда удаленный узел согласовывает VPN
   • Только исходный — Локальный узел будет согласовывать VPN, но не будет отвечать, если удаленный попытается согласовать
8. Нажмите зеленую кнопку Добавить рядом с Защищенные сети
   • Добавьте одну или несколько сетей позади этого устройства, которые будут доступны через VPN
   • Из FMC 6.2.3, у вас есть возможность использовать объект подсети / IP-адреса или расширенный список доступа

Теперь настройте удаленную конечную точку (не управляемую нами):

1. Рядом с узлом Node B нажмите зеленую кнопку Добавить
2. Выберите Экстранет в качестве устройства
3. Введите понятное имя устройства
4. Введите IP-адрес устройства
5. Для версии 6.2.3 и новее будет возможность добавить карту сертификата (нам она не нужна, так как мы используем предварительные ключи)
6. Как и раньше, добавляем защищенную сеть

Далее мы настраиваем IKE (туннель фазы 1).Доступные нам настройки зависят от версии IKE, которую мы используем.

1. Перейти на вкладку IKE
2. Выберите подходящую политику (мы используем предопределенную политику AES-SHA-SHA )
3. Выберите тип аутентификации
   • Предварительно общий ручной ключ вводится вручную на обоих концах
   • Предварительно общий автоматический ключ управляется FMC. Это требует, чтобы FMC управлял обоими концами.
   • Сертификат можно использовать, но для этого требуется настроить точку доверия.

А теперь настраиваем IPSec (туннель фаза-2):

1. Перейти на вкладку IPSec
2. Выберите подходящее предложение IPSec (если вы не уверены, оставьте значения по умолчанию)
3. Включить внедрение обратного маршрута для добавления защищенных сетей в локальную таблицу маршрутизации
4. При желании включите Perfect Forward Secrecy.Если вы не уверены, оставьте его включенным.

Дополнительная конфигурация

Есть несколько заключительных моментов, которые вы можете рассмотреть для своей среды.

Исключение NAT — Если вы используете NAT, вам необходимо создать исключение для трафика, проходящего через VPN.

Dynamic Routing — Reverse Route Injection помещает маршрут в локальную таблицу маршрутизации, но дальше не идет.Если вы хотите рекламировать этот маршрут, вам нужно перераспределить его в свой IGP.

Развертывание политики — помните, что ваши изменения не вступят в силу, пока вы не развернете их на своих устройствах.

Проверка и мониторинг

Самое простое место для проверки статуса вашей VPN — это FMC.

Перейдите к System -> Health -> Events .Затем нажмите VPN Status .

Оставшаяся проверка выполняется через интерфейс командной строки FTD. Когда вы находитесь в интерфейсе командной строки, запустите system support Diagnostic-cli , чтобы получить консоль в стиле Classic-ASA.

Отсюда запустите пакет-трассировщик для моделирования трафика между защищенными сетями.

ПРИМЕЧАНИЕ. Я использовал здесь поддельный IP-адрес, поэтому я не передаю никакой реальной сетевой информации.

Моделирование трафика с помощью Packet-Tracer

 firepower # packet-tracer внутри icmp 10.6.26.201 8 0 10.8.1.1

Фаза 1
Тип: UN-NAT
Подтип: статический
Результат: РАЗРЕШИТЬ
Конфиг:
nat (Inside, Outside) источник статический Network-Test Network-Test назначение статический Network-Remote Network-Remote описание VPN Exemption
Дополнительная информация:
Перенаправление NAT на исходящий интерфейс За пределами
Неперевести с 10.8.1.1/0 на 10.8.1.1/0

Фаза 2
Тип: ACCESS-LIST
Подтип: журнал
Результат: РАЗРЕШИТЬ
Конфиг:
группа доступа CSM_FW_ACL_ global
список доступа CSM_FW_ACL_ расширенное доверие icmp любой любой идентификатор правила 268436517 журнал событий конец потока
список доступа CSM_FW_ACL_ идентификатор правила примечания 268436517: ПОЛИТИКА ПРЕФИЛЬТРА: предварительный фильтр сайта
список доступа CSM_FW_ACL_ идентификатор правила примечания 268436517: ПРАВИЛО: ICMP
Дополнительная информация:

Фаза: 3
Тип: CONN-SETTINGS
Подтип:
Результат: РАЗРЕШИТЬ
Конфиг:
карта классов класс по умолчанию
 соответствовать любому
карта политик global_policy
 класс class-default
  установить расширенные параметры подключения UM_STATIC_TCP_MAP
  установить декремент соединения-ttl
сервис-политика global_policy global
Дополнительная информация:

Фаза: 4
Тип: NAT
Подтип:
Результат: РАЗРЕШИТЬ
Конфиг:
nat (Inside, Outside) источник статический Network-Test Network-Test назначение статический Network-Remote Network-Remote описание VPN Exemption
Дополнительная информация:
Статический перевод 10.С 6.26.201 / 0 по 10.6.26.201/0

Фаза: 5
Тип: NAT
Подтип: за сеанс
Результат: РАЗРЕШИТЬ
Конфиг:
Дополнительная информация:

Фаза: 6
Тип: IP-ОПЦИИ
Подтип:
Результат: РАЗРЕШИТЬ
Конфиг:
Дополнительная информация:

Фаза: 7
Тип: ПРОВЕРКА
Подтип: np-inspect
Результат: РАЗРЕШИТЬ
Конфиг:
Дополнительная информация:

Фаза: 8
Тип: VPN
Подтип: шифрование
Результат: РАЗРЕШИТЬ
Конфиг:
Дополнительная информация:

Фаза: 9
Тип: NAT
Подтип: rpf-check
Результат: РАЗРЕШИТЬ
Конфиг:
nat (Inside, Outside) источник статический Network-Test Network-Test назначение статический Network-Remote Network-Remote описание VPN Exemption
Дополнительная информация:

Фаза: 10
Тип: ПОТОК-СОЗДАНИЕ
Подтип:
Результат: РАЗРЕШИТЬ
Конфиг:
Дополнительная информация:
Новый поток создан с идентификатором 41815442, пакет отправлен следующему модулю

Фаза: 11
Тип: МАРШРУТ-ПРОСМОТР
Подтип: Resolve Egress Interface
Результат: РАЗРЕШИТЬ
Конфиг:
Дополнительная информация:
найден следующий переход 10.222.254.22 с использованием egress ifc Outside

Фаза: 12
Тип: ПОТОК-ПРОСМОТР
Подтип:
Результат: РАЗРЕШИТЬ
Конфиг:
Дополнительная информация:
Найден поток с идентификатором 41634632, используя существующий поток

Фаза: 13
Тип: CAPTURE
Подтип:
Результат: РАЗРЕШИТЬ
Конфиг:
Дополнительная информация:
Список доступа MAC

Результат:
интерфейс ввода: снаружи
вход-статус: вверх
вход-линия-статус: вверх
выходной интерфейс: снаружи
статус вывода: вверх
статус строки вывода: вверх
Действие: разрешить 

Теперь давайте подтвердим фазу 1 (IKE).Вы можете обнаружить, что приведенные ниже команды изначально не возвращают никаких данных.

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

Подтвердить Фазу 1

! Можно использовать IKEv1 или v2

Огневая мощь # показать крипто ikev1 sa

IKEv1 SA:

   Активная SA: 1
    Rekey SA: 0 (туннель будет сообщать 1 активный и 1 Rekey SA во время смены ключа)
Всего IKE SA: 1

1 узел IKE: 258.6.18.25
    Тип: L2L Роль: инициатор
    Повторный ключ: нет Состояние: MM_ACTIVE 

Теперь посмотрим на фазу 2 (IPSec). В частности, ищите инкапсы и декапс .

Encaps — это пакеты, которые мы инкапсулируем и отправляем через VPN. Decap — это пакеты, которые отправляются нам через VPN и которые нам нужно декапсулировать.

Подтвердить этап 2

 огневая мощь # sh crypto ip sa
интерфейс: снаружи
    Тег криптокарты: CSM_Outside_map, seq num: 2, local addr: 10.222,254,2

      список доступа CSM_IPSEC_ACL_1 расширенное разрешение ip 10.6.26.0 255.255.255.0 10.8.0.0 255.255.0.0
      локальный идентификатор (адрес / маска / прот / порт): (10.6.26.0/255.255.255.0/0/0)
      удаленный идентификатор (адрес / маска / прот / порт): (10.8.0.0/255.255.0.0/0/0)
      current_peer: 258.6.18.25


      #pkts encaps: 43, #pkts encrypt: 43, #pkts digest: 43! Инкапсулируем трафик и отправляем
      #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0! Мы не получаем обратный трафик для декапсуляции
      #pkts сжато: 0, #pkts распаковано: 0
      #pkts не сжат: 43, #pkts comp failed: 0, #pkts decomp failed: 0
      # успехов перед фрагментами: 0, # ошибок перед фрагментами: 0, # созданных фрагментов: 0
      # Отправленных PMTU: 0, # PMTU rcvd: 0, # декапсулированных FRG, требующих повторной сборки: 0
      #TFC rcvd: 0, #TFC отправлено: 0
      # Valid ICMP Errors rcvd: 0, # Invalid ICMP Errors rcvd: 0
      # отправить ошибки: 0, #recv ошибки: 0

      местная криптография endpt.: 10.222.254.2/4500, удаленный криптографический конец: 258.6.18.25/4500
      путь mtu 1500, служебные данные IPsec 82 (52), мультимедийный mtu 1500
      Оставшееся время PMTU (сек): 0, политика DF: copy-df
      Проверка ошибок ICMP: отключена, пакеты TFC: отключены
      текущий исходящий spi: 6EAB4C07
      текущий входящий spi: B53ECF25

    входящий esp sas:
      spi: 0xB53ECF25 (3040792357)
         преобразовать: esp-aes-256 esp-sha-hmac без сжатия
         в настройках использования = {L2L, Tunnel, NAT-T-Encaps, PFS Group 2, IKEv1,}
         слот: 0, conn_id: 12288, криптокарта: CSM_Outside_map
         sa time: оставшееся время жизни ключа (кБ / сек): (3915000/26892)
         Размер IV: 16 байт
         Поддержка обнаружения повтора: Y
         Растровое изображение антиповтора:
          0x00000000 0x00000001
    исходящий esp sas:
      spi: 0x6EAB4C07 (1856719879)
         преобразовать: esp-aes-256 esp-sha-hmac без сжатия
         в настройках использования = {L2L, Tunnel, NAT-T-Encaps, PFS Group 2, IKEv1,}
         слот: 0, conn_id: 12288, криптокарта: CSM_Outside_map
         sa time: оставшийся срок службы ключа (кБ / сек): (3914997/26892)
         Размер IV: 16 байт
         Поддержка обнаружения повтора: Y
         Растровое изображение антиповтора:
          0x00000000 0x00000001 

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

Начните с проверки, находится ли маршрут в FTD, как показано ниже. Затем убедитесь, что он успешно перераспределяется в ваш IGP.

Проверить статический маршрут VPN

 firepower # показать маршрут статический
! --- Вывод удален для краткости ---

Последний шлюз - 10.225.254.54 в сеть 0.0.0.0.

S * 0.0.0.0 0.0.0.0 [1/0] через 10.222.254.2, снаружи
V 10.8.0.0 255.255.0.0 подключен через VPN (объявлен), за пределами 

Список литературы

Cisco — VPN типа «сеть-сеть» для защиты от угроз

.