{"draftJsState":{"blocks":[{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":18,"offset":973,"style":"BOLD"}],"text":"Развивая IT-инфраструктуру рано или поздно приходит задача \nинтегрироваться с какими-либо сервисами крупной организации. Это может \nбыть, например, банк или оператор связи. Как правило в крупных \nорганизациях действуют устоявшиеся политики информационной безопасности, которые в частности требуют реализации сервиса с внешней по отношению к ним инфраструктурой через шифрованные каналы — IPSec. В то же время в небольших организациях нет опыта организации таких \nсхем, а из оборудования есть только VDS с Linuxом на борту. Более того, к\n моему удивлению, в рунете практически нет материалов с описанием \nинструментов траблшутинга под Linux. Попробуем устранить этот пробел и \nописать практическую часть настроек.\n\nОбщая схема сервиса представлена ниже. Как правило, в крупных \nорганизациях все уже стандартизировано, поставлено на поток, всякие \nвозможные шифрования и прочие сетевые штуки делаются на отдельном \nоборудовании (циски-джуниперы и иже с ними), и, что важнее, отдельными людьми (возможно каждый синий квадратик на схеме ниже обслуживают разные люди). У вас же одна виртуалка, с которой будет и запускаться сервис, и организовываться IPSec.","type":"unstyled","key":"2uddi"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"","type":"unstyled","key":"ob5d"},{"data":{"image":{"id":"67c0294e2506a046443cdb72"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"","type":"atomic:image","key":"fukrm"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":21,"offset":201,"style":"ITALIC"},{"length":11,"offset":296,"style":"ITALIC"},{"length":11,"offset":372,"style":"ITALIC"}],"text":"Обратите внимание, сам IPSec организовывается между одними IP-адресами (в моем примере 10.0.255.1 <-> 10.0.1.1), а сам сервис — между другими (192.168.255.1<-> 192.168.1.1). Такие схемы еще называются IPSec Network-Network.\n\nПростой пример — вы работаете в молодой, но очень амбициозной компании СуперСервис, и вам надо организовать взаимодействие с закрытым API компании МегаТелеком.\n Ваша инфраструктура — один сервер VDS, инфраструктура партнера — куча \nсетевого и серверного оборудования. Задача делится на два этапа:","type":"unstyled","key":"ck7fu"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Организовать транспорт (как будет происходить межсетевое взаимодействие).","type":"ordered-list-item","key":"48ddh"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Настроить сервис (запустить приложения непосредственно на серверах).","type":"ordered-list-item","key":"3tt1b"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":11,"offset":15,"style":"ITALIC"},{"length":11,"offset":131,"style":"ITALIC"},{"length":5,"offset":276,"style":"ITALIC"},{"length":19,"offset":163,"style":"BOLD"},{"length":5,"offset":234,"style":"BOLD"}],"text":"Итак, менеджер СуперСервис решил организовать подключение к какой-то крупной организации для решения бизнес-задачи. Он обратился к МегаТелеком, на что ему выслали технические условия по подключению. Одно из этих условий — организация IPSec. Это условие пришло в виде таблички excel, пример которой я представил ниже. На картинке я желтым выделил технически значимые параметры. Формат может отличаться, но суть остается той же.","type":"unstyled","key":"efesl"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"","type":"unstyled","key":"dmq2h"},{"data":{"image":{"id":"67c029703f9aba669b321f61"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"","type":"atomic:image","key":"24kon"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Изначально он приходит не заполненный с вашей стороны, его надо \nзаполнить и отправить на согласование партнеру. После согласования можно\n садиться и пробовать настраивать вашу Linux-машинку.","type":"unstyled","key":"2pi90"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Концепция IPSec","type":"header-three","key":"7qa4v"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":5,"offset":246,"style":"BOLD"},{"length":26,"offset":557,"style":"BOLD"},{"length":20,"offset":832,"style":"BOLD"},{"length":6,"offset":1000,"style":"BOLD"},{"length":2,"offset":585,"style":"ITALIC"},{"length":2,"offset":670,"style":"ITALIC"}],"text":"Далее я приведу немного теории для людей, совсем не знакомых с \nтехнологией. Все, что я дальше опишу, относится к чистому Ethernet и \nIPv4. Я не буду вдаваться в алгоритмы шифрования, обмена ключами, вместо\n этого сосредоточусь на сетевой части.\nIPSec — набор техник и протоколов по организации защищенного соединения.\nВ отличии от прочих технологий туннелирования (GRE, PPP, L2TP, даже \nMPLS-TE) для IPSec не создается явных туннельных интерфейсов, через \nкоторые можно маршрутизировать трафик. Вместо этого в IPSec \nпредусмотрена концепция так называемых Security Assotiations (SA). SA и есть туннель от одного сетевого устройства к другому. Но не стоит забывать, что SA — не сетевой интерфейс в нормальном понимании этого слова, классическая маршрутизация здесь не работает. Вместо таблицы маршрутизации здесь работает концепция Security Policy (SP). Мы явно прописываем что-то типа аксес-листа (ACL) для пропуска трафика через определенную SA. Все эти вещи определены в так называемом фреймворке ISAKMP.","type":"unstyled","key":"b7jv3"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":6,"offset":0,"style":"BOLD"},{"length":9,"offset":384,"style":"BOLD"}],"text":"ISAKMP — описание процедур IPSec, в литературе \nназывают его фреймворком. В нем описываются термины SA, SP, SAD \n(Security Assotiations Database), SPD (Security Policy Database), \nнеобходимость установки вспомогательных туннелей… ISAKMP построен так, \nчтобы не зависеть от технологий туннелирования, алгоритмов \nаутентификации и шифрования. Он просто вводит необходимые определения.\n\nIKE(v1/2) — непосредственно протокол аутентифиации. Он уже реализовывает алгоритмы обмена ключами и их применение.\n\nБлагодаря концепции Cisco сейчас ISAKMP и IKE считаются синонимами.","type":"blockquote","key":"39dhj"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":31,"offset":478,"style":"BOLD"},{"length":6,"offset":536,"style":"ITALIC"}],"text":"Перед шифрованием трафика стороны должны договориться о параметрах (и \nключах) этого шифрования. Для этого между обоими сторонами поднимается \nвспомогательный туннель (его еще называют ISAKMP туннель), который \nдействует все время. Туннель этот двунаправленный, представляет из себя \nсоединение по UDP (по умолчанию на порту 500). Для организации этого \nвспомогательного туннеля стороны должны проверить подлинность друг друга (должен совпасть пароль). Этим занимается протокол IKEv1/2 (Internet Key Exchange). И уже по организованному ISAKMP туннелю стороны договариваются о шифровании непосредственно пользовательского трафика.","type":"unstyled","key":"6g07l"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":50,"offset":0,"style":"BOLD"}],"text":"Собственно организация IPSecа делится на две фазы:","type":"unstyled","key":"7hghl"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Создание вспомогательного туннеля ISAKMP","type":"ordered-list-item","key":"6c89l"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Создание туннеля пользовательских данных","type":"ordered-list-item","key":"5cbtp"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":6,"offset":71,"style":"ITALIC"},{"length":2,"offset":98,"style":"ITALIC"}],"text":"Как я писал, в концепции IPSec (а уже правильнее говорить, в концепции ISAKMP) туннели называются SA.\n\nПервая фаза (организация ISAKMP SA) может осуществляться в двух режимах:","type":"unstyled","key":"5ld5d"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":4,"offset":0,"style":"BOLD"}],"text":"main — стороны поочередно обмениваются параметрами \nсогласования. Считается более безопасным, используется для постоянных \nканалов (наш случай).","type":"ordered-list-item","key":"7brpg"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":10,"offset":0,"style":"BOLD"}],"text":"aggressive — инициатор в одном сообщении отправляет все \nнеобходимые параметры согласования, используется при подключении \nудаленного пользователя для временной сессии (чтобы быстрее).","type":"ordered-list-item","key":"9c1ld"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":8,"offset":19,"style":"BOLD"},{"length":16,"offset":39,"style":"BOLD"},{"length":26,"offset":338,"style":"BOLD"},{"length":36,"offset":367,"style":"BOLD"},{"length":12,"offset":750,"style":"BOLD"},{"length":10,"offset":1127,"style":"BOLD"}],"text":"Надо понимать, что основные SA-туннели однонаправленные. Для двусторонней передачи данных по IPSec каналу должно быть два туннеля: источник (src) → получатель (dst) и наоборот.\n\nВо всех способах шифрования в оригинальный IP-пакет добавляются \nдополнительные заголовки, происходит инкапсуляция. Существует два \nспособа этой инкапсуляции — AH (Authentication Header) и ESP (Encapsulation Security Payload).\n AH только аутентифицирует пакет (подписывает цифровой подписью \nотправителя), ESP и аутентифицирует (подписывает), и шифрует. На \nсегодняшний день AH уже практически не используется, все упаковывают в \nESP.\n\nШифровать и аутентифицировать исходный IP-пакет можно без учета \nIP-заголовка (транспортный режим) или вместе с ним (туннельный режим). Транспортный\n используется тогда, когда планируется организовать свои туннели по \nдругим технологиям (не IPSec/ESP). Например, GRE, l2tp, ppp. Для целей \nподключения какого-то сервиса ко внутренней инфраструктуре большой \nорганизации практически не используется. Я использовал такой сценарий \nдля объединения нескольких офисов в один VPN через IPSec-и. Нам же более\n интересен туннельный режим. Как видно из картинки, здесь добавляется один дополнительный IP-заголовок.","type":"unstyled","key":"880ug"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"","type":"unstyled","key":"3n2mk"},{"data":{"image":{"id":"67c029c589ba58323c1f58fa"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"","type":"atomic:image","key":"31qmb"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":2,"offset":452,"style":"ITALIC"},{"length":2,"offset":463,"style":"ITALIC"}],"text":"Кстати, есть реальный пример использования AH-инкапсуляции. Предположим, у нас есть две сети, подключенные к разным маршрутизаторам. Хосты должны передавать информацию с MTU 1500 байт без фрагментации, но у нас есть промежуточный участок, который поддерживает только 1380 байт. Вся трасса доверенная. Мы можем воспользоваться тем, что IPSec не создает туннельных интерфейсов, в классическом смысле через которые трафик не маршрутизируется. Мы создадим SA туннель AH типа (нам же не надо шифровать), тогда трафик пойдет него. В трафике фрагментироваться будут только внешние IP-пакеты (по внешним IP-заголовкам), внутренние будут пересобираться без изменений.","type":"unstyled","key":"5a735"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"","type":"unstyled","key":"8448d"},{"data":{"image":{"id":"67c029e56709280547e2ac20"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"","type":"atomic:image","key":"4222b"},{"data":{},"depth":0,"entityRanges":[{"key":0,"length":4,"offset":315}],"inlineStyleRanges":[{"length":3,"offset":33,"style":"ITALIC"},{"length":23,"offset":44,"style":"BOLD"}],"text":"Обратите внимание, что заголовок ESP встает до транспортных TCP/UDP.\n Помните, в заголовке IP-пакета есть поле Protocol? На основе этого поля\n сетевое оборудование (да и конечные хосты) корректно обрабатывают \nIP-пакеты. Так вот для ESP свой номер — 50. Полный список протоколов для\n этого поля можно посмотреть на вики, бывает весьма полезно.","type":"unstyled","key":"44uag"},{"data":{"image":{"id":"67c029fba8b0cc51e60de489"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"","type":"atomic:image","key":"54me9"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":27,"offset":353,"style":"BOLD"}],"text":"Отсутствие заголовка транспортного уровня (TCP/UDP/ICMP уже \nзашифрованы!) накладывает ограничение на технологии типа NAT. Вспомните, NAT с трансляцией портов (overload, PAT, MASQARADE, у него много имен) работает на основе портов транспортных протоколов. А в зашифрованном туннеле IPSec их нет! Для преодоления этой проблемы есть такая технология, как IPSec NAT-Traversal (NAT-T). В ходе первой фазы \nстороны согласовывают возможность использовать NAT-T. Если обе стороны \nподдерживают NAT-T (да еще и на одинаковых UDP-портах), тогда в итоговых\n туннелях для трафика добавляется заголовок UDP, с которым пакеты уже \nпройдут через маршрутизаторы с трансляцией сетевых адресов.","type":"unstyled","key":"30pbf"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":20,"offset":146,"style":"BOLD"},{"length":18,"offset":518,"style":"ITALIC"},{"length":16,"offset":543,"style":"ITALIC"}],"text":"Сам по себе туннель не поднимется, нужно направить туда трафик. Как я \nписал выше, здесь не работают правила маршрутизации, надо писать \nполитики Security Policy (SP).\n\nПолитики состоят из адреса источника, адреса назначения, направления \n(in, out, fwd) и параметров пользовательских туннелей (здесь как раз \nописываются ESP это будет или AH, туннельный вариант или транспортный). \nЭто больше похоже на организацию правил для NATа. NATу тоже недостаточно\n записей таблицы маршрутизации. И там тоже указываются правила откуда, куда и как, а не куда и через что. И также неверным движением руки можно завалить всю связь на удаленном сервере.","type":"unstyled","key":"ffjh4"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Все манипуляции с IPSec добавляют заголовки служебной \nинформации. Минимум они съедят еще 40 байт от исходного пакета. Таким \nобразом, например, при стандартном MTU для PPPoE в 1380 байт соединений \nреальное MTU будет < 1340.","type":"blockquote","key":"5a1jh"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"","type":"unstyled","key":"30kgh"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Практика","type":"header-three","key":"b5u6l"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":20,"offset":109,"style":"ITALIC"}],"text":"Займемся практикой на примере DEB-дистрибутивов. Я буду рассматривать только случай с авторизацией на основе pre-shared-key (PSK), будем настраивать схему из начала статьи.\n\nСам по себе IPSec поддерживается ядром, но поддержка эта весьма \nограничена. В действительности ядреные модули занимаются только тем, что\n связано с шифрованием и уже полученными (переданными в ядро) ключами — \nобработка пакетов. А чтобы передать туда параметры и правила, с которыми\n нужно обрабатывать трафик, требуется отдельное программное обеспечение.\n В качестве такого софта есть несколько решений:","type":"unstyled","key":"duu8m"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"KAME, перекочевавший из BSD","type":"ordered-list-item","key":"cmegj"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"xSWAN (strongswan, freeswan, libreswan, etc)","type":"ordered-list-item","key":"akut1"},{"data":{},"depth":0,"entityRanges":[{"key":1,"length":9,"offset":0}],"inlineStyleRanges":[],"text":"shorewall","type":"ordered-list-item","key":"5efu1"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Мне показался самым простым (самым предсказуемым) вариант KAME, его и будем крутить дальше.","type":"unstyled","key":"38qa8"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"#Для deb-дистрибутивов команда сама подтянет необходимые ядреные модули\nroot@localhost: ~# apt-get install racoon ipsec-tools","type":"unstyled","key":"8e9ea"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Традиционно KAME состоял из двух компонент","type":"unstyled","key":"5ife3"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":6,"offset":7,"style":"BOLD"},{"length":6,"offset":38,"style":"ITALIC"}],"text":"Демона racoon для управления туннелем ISAKMP.","type":"ordered-list-item","key":"95ep0"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":6,"offset":8,"style":"BOLD"}],"text":"Утилиты setkey для управления SA-туннелей с данными.","type":"ordered-list-item","key":"8jc8m"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":6,"offset":18,"style":"ITALIC"}],"text":"Начнем с первого. Racoon отвечает за параметры авторизации туннелей в рамках IKE. Это демон, он настраивается одним конфигурационным файлом (/etc/racoon.conf), запускается обычным init-скриптом (/etc/init.d/racoon ).","type":"unstyled","key":"d6lin"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":39,"offset":0,"style":"BOLD"}],"text":"root@localhost: ~# cat /etc/racoon.conf","type":"unstyled","key":"8phd0"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"# Практически все данные в разделах remote и sainfo берутся из первоначального шаблона\n#\n# Мы рассмотрим простейший пример с PSK авторизацией\npath pre_shared_key \"/etc/racoon/psk.txt\";\nlog debug;\nlisten {\n# Указываем интерфейс, с которого будет строиться будущий ISAKMP туннель\n isakmp 10.0.1.1 [500];\n strict_address;\n}\n\n# В разделе remote перчислены настройки для первой фазы IPSec.\n# Это в некотором смысле аналог tunnel-group в ASA.\n# Вместо конкретного IP-адреса можно указать anonymous\n# Это будет означать возможность подключения к вам с любого адреса. \n# Так делаются присоединения типа user-network\n# remote anonymous\n \nremote 10.0.255.1 {\n nat_traversal off;\n exchange_mode main;\n my_identifier address 10.0.1.1;\n proposal {\n encryption_algorithm 3des;\n hash_algorithm sha1;\n authentication_method pre_shared_key;\n dh_group modp1024;\n lifetime time 86400 sec;\n }\n}\n\n# Вторая фаза IPSec. Аналог transform-set в ASA.\n#\n# Предполагается, что для разных адресов взаимодействия\n# можно применять разные параметры шифрования второй фазы.\n# Конкретизация сервисов как раз указывается в первой строчке\n# sainfo address address \n# Скорее всего вам это не понадобится, вы будете писать первую строку так\n# sainfo anonymous \n\nsainfo address 192.168.1.1 any address 192.168.255.1 any {\n pfs_group modp1024;\n lifetime time 28800 sec;\n encryption_algorithm 3des;\n authentication_algorithm hmac_sha1;\n compression_algorithm deflate;\n}","type":"unstyled","key":"4q5r0"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":42,"offset":0,"style":"BOLD"}],"text":"root@localhost: ~# cat /etc/racoon/psk.txt","type":"unstyled","key":"4gtsv"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"# Файлик с PSK-ключами\n# Формат \n# Важно - владелец файла должен быть такой же, от чьего имени запускается racoon\n10.0.255.1 SUPERPASSWORD","type":"unstyled","key":"ejnkb"},{"data":{},"depth":0,"entityRanges":[{"key":2,"length":17,"offset":26},{"key":3,"length":12,"offset":657}],"inlineStyleRanges":[{"length":6,"offset":70,"style":"ITALIC"},{"length":10,"offset":337,"style":"ITALIC"},{"length":6,"offset":499,"style":"ITALIC"},{"length":6,"offset":575,"style":"ITALIC"},{"length":7,"offset":303,"style":"BOLD"}],"text":"Как всегда, подробности в man 5 racoon.conf\n\nДальше займемся утилитой setkey. Она тоже запускается как демон (/etc/init.d/setkey ), но по факту она выполняет скрипт /etc/ipsec-tools.conf. Как я и говорил, она уже задает создает туннели для пользовательского трафика. А именно задает SA и SP для них. Это что-то вроде crypto-map на ASA. Самый простой вариант для нас — добавить просто SP. Тогда SA построится автоматически исходя из параметров второй фазы, указанной в настройках racoon.\nНо есть возможность вообще не использовать параметры второй фазы из racoon, а задать SA через эту утилиту. Подробности и синтаксис можно посмотреть в man 8 setkey. А я же приведу приведу пример простейшей конфигурации.","type":"unstyled","key":"6r5jm"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":44,"offset":0,"style":"BOLD"}],"text":"root@localhost: ~# cat /etc/ipsec-tools.conf","type":"unstyled","key":"nhg1"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"flush;\nspdflush;\n\t\nspdadd 192.168.1.1/32 192.168.255.1/32 any -P out ipsec\n esp/tunnel/10.0.1.1-10.0.255.1/require;\n\t\nspdadd 192.168.255.1/32 192.168.1.1/32 any -P in ipsec\n esp/tunnel/10.0.255.1-10.0.1.1/require;","type":"unstyled","key":"fliob"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"","type":"unstyled","key":"922cu"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":6,"offset":26,"style":"ITALIC"},{"length":8,"offset":50,"style":"ITALIC"}],"text":"На текущий момент утилиту setkey дублирует модуль iproute2.\n\nВ рамках него есть две команды управления записями SA и SP.","type":"unstyled","key":"6cl3i"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":5,"offset":8,"style":"BOLD"}],"text":"ip xfrm state","type":"ordered-list-item","key":"eoab0"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":6,"offset":8,"style":"BOLD"}],"text":"ip xfrm policy","type":"ordered-list-item","key":"kb4p"},{"data":{},"depth":0,"entityRanges":[{"key":4,"length":13,"offset":118}],"inlineStyleRanges":[{"length":2,"offset":102,"style":"ITALIC"}],"text":"Помимо управления этой же утилитой можно смотреть состояние организованных SA и применяемых к трафику SP. Подробнее в man 8 ip-xfrm.","type":"unstyled","key":"b6dcp"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":5,"offset":149,"style":"BOLD"},{"length":11,"offset":277,"style":"ITALIC"},{"length":11,"offset":1346,"style":"ITALIC"},{"length":7,"offset":1726,"style":"ITALIC"},{"length":13,"offset":1756,"style":"ITALIC"}],"text":"С моей точки зрения здесь подходит первый вариант.\n\n\n\nМы можем добавить на наш интерфейс дополнительный (secondary) IP-адрес, при этом лучше сделать alias для этого интерфейса\n\nroot@localhost: ~# ip addr add 192.168.1.1/32 dev eth1 label eth1:1\n\nи настроить маршрут до сервера Мегателеком с этого IP-адреса.\n\nroot@localhost: ~# ip route add 192.168.255.1/32 dev eth1:1 src 192.168.1.1\n\nНо если так сделать, ничего не заведется. Дело в том, что при добавлении\n маршрута в таком виде Linux-станция будет пытаться определить MAC-адрес\n получателя, делать она это будет через ARP… Компьютер будет слать \nзапросы ARP Who has IP 192.168.255.1. Так как 192.168.255.1\n нет в той же сети, где и 192.168.1.1 (маска /32!), ответа на ARP не \nбудет. Зато при попытке соединения будет возвращаться с локального \nIP-адреса будет возвращаться No route to host. Чтобы это победить, нам надо задать статическую ARP-запись:\n\nroot@localhost: ~# arp -s 192.168.255.1 00:00:00:00:00:01 -i eth1:1\n\nТакой вот лайфхак. Кстати, такие манипуляции могут привести не совсем к \nкоректной работе IP-стека Linux. В одном из случаев команды ip route не приводили к нужному результату, пришлось перезагружать сетевой стек.Взгляните еще раз на изначальную табличку. Там указаны \nразные IP-адреса для IPSec и сервиса. По внутреннему IP-адресу идет \nфильтрация внутри инфраструктуры Мегателеком. Но у нас всего лишь\n одна виртуальная машина. На ней должен как-то появиться внутренний \nIP-адрес, и пакеты в туннель должны уходить именно с него. Есть \nнесколько вариантов добиться этого сценария:Статический маршрут без определения некстхопа, но с явным указанием исходящего интерфейса и IP-адреса.\nЗадание маршрутов на основе policy based routing (PBR в Linux ака ip rule).\nТрансляция адресов (NAT/MASQARADE).\n","type":"blockquote","key":"7as7f"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Проверка работоспособности","type":"header-three","key":"fvgu9"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Не забывайте, туннель поднимется только тогда, когда в него пойдет \nтрафик! Надо запустить пинг с конкретного интерфейса (IP-адреса) до \nназначения. \n\nroot@localhost: ~# ping -I 192.168.1.1 192.168.255.1\n\nС небольшой задержкой должны быть ответы с обратной стороны (если конечно ICMP нигде не закрыт на участке).\n\nМы можем увидеть, поднялся ли ISAKMP-туннель","type":"unstyled","key":"3f53u"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":24,"offset":0,"style":"BOLD"}],"text":"racoonctl show-sa isakmp","type":"unstyled","key":"6q7ld"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"root@localhost: ~# racoonctl show-sa isakmp\nDestination Cookies Created\n10.0.1.1.500 356a7e11111a93f:367111530375c065 2018-10-02 09:18:28","type":"unstyled","key":"8mjdq"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Также мы можем посмотреть туннели с пользовательскими данными","type":"unstyled","key":"8qvst"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":21,"offset":0,"style":"BOLD"}],"text":"racoonctl show-sa esp","type":"unstyled","key":"8h07p"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"10.0.1.1 10.0.255.1\n esp mode=tunnel spi=2148175815(0x800a8fc7) reqid=0(0x00000000)\n E: 3des-cbc 799e587f 6a2b4b78 5590cc2a 3d3ee331 f7e7f472 01abcdef\n A: hmac-sha1 01c5161f 46679a36 5d07ee9d f159fc9a 01abcdef\n seq=0x00000000 replay=4 flags=0x00000000 state=mature\n created: Oct 2 09:22:44 2018 current: Oct 2 10:39:21 2018\n diff: 4597(s) hard: 28800(s) soft: 23040(s)\n last: Oct 2 09:22:45 2018 hard: 0(s) soft: 0(s)\n current: 84(bytes) hard: 0(bytes) soft: 0(bytes)\n allocated: 1 hard: 0 soft: 0\n sadb_seq=1 pid=3764 refcnt=0\n10.0.255.1 10.0.1.1\n esp mode=tunnel spi=45614328(0x02b804f8) reqid=0(0x00000000)\n E: 3des-cbc 97cedcf1 644e8bbb c22b4e2c fa08a874 01abcdef 211ad19e\n A: hmac-sha1 1ab3e79d 3fd924a0 01abcdef 6c9ac89a 01abcdef \n seq=0x00000000 replay=4 flags=0x00000000 state=mature\n created: Oct 2 09:22:44 2018 current: Oct 2 10:39:21 2018\n diff: 4597(s) hard: 28800(s) soft: 23040(s)\n last: Oct 2 09:22:45 2018 hard: 0(s) soft: 0(s)\n current: 84(bytes) hard: 0(bytes) soft: 0(bytes)\n allocated: 1 hard: 0 soft: 0\n sadb_seq=0 pid=3764 refcnt=0","type":"unstyled","key":"5s1f3"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":7,"offset":17,"style":"ITALIC"},{"length":11,"offset":142,"style":"BOLD"}],"text":"Бывает полезно в tcpdump посмотреть логику установления соединения. Здесь можно также увидеть фазы установления соединения и уже передаваемый шифрованный в ESP трафик. Конечно есть техники его расшифровки, но обычно такого вывода уже достаточно.","type":"unstyled","key":"k2m0"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":50,"offset":0,"style":"BOLD"}],"text":"root@localhost: ~# tcpdump -i eth1 host 10.0.255.1","type":"unstyled","key":"60kbg"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"18:01:06.409631 IP 10.0.1.1.500 > 10.0.255.1.500: isakmp: phase 1 I ident\n18:01:06.439276 IP 10.0.255.1.500 > 10.0.1.1.500: isakmp: phase 1 R ident\n18:01:06.440840 IP 10.0.1.1.500 > 10.0.255.1.500: isakmp: phase 1 I ident\n18:01:06.475244 IP 10.0.255.1.1.500 > 10.0.1.1.500: isakmp: phase 1 R ident\n18:01:06.477032 IP 10.0.1.1.500 > 10.0.255.1.500: isakmp: phase 1 I ident[E]\n18:01:06.487785 IP 10.0.255.1.500 > 10.0.1.1.500: isakmp: phase 1 R ident[E]\n18:01:06.488048 IP 10.0.1.1.500 > 10.0.255.1.500: isakmp: phase 2/others I inf[E]\n18:01:07.412451 IP 10.0.1.1.500 > 10.0.255.1.500: isakmp: phase 2/others I oakley-quick[E]\n18:01:07.465363 IP 10.0.255.1.500 > 10.0.1.1.500: isakmp: phase 2/others R oakley-quick[E]\n18:01:07.465940 IP 10.0.1.1.500 > 10.0.255.1.500: isakmp: phase 2/others I oakley-quick[E]\n18:01:08.467373 IP 10.0.1.1 > 10.0.255.1: ESP(spi=0x7aabfa82,seq=0x1), length 116\n18:01:08.480141 IP 10.0.255.1 > 10.0.1.1: ESP(spi=0x0386f867,seq=0x1), length 116","type":"unstyled","key":"elaa1"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"При удаленном подключении по SSH, чтобы не плодить кучу окон удобно запускать tcpdump в фоне:\n\nroot@localhost: ~# tcpdump -i eth1 -w ipsec.pcap esp &\n\nЗапускаем ping, telnet, netcat…\n\nroot@localhost: ~# killall tcpdump\n\nroot@localhost: ~# tcpdump -vr ipsec.pcap","type":"blockquote","key":"1111b"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Также в логах можно увидеть успешный статус установления соединения. В нем видно успешное установление обоих фаз IPSec.","type":"unstyled","key":"foo6s"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":43,"offset":0,"style":"BOLD"}],"text":"root@localhost: ~# cat /var/log/daemon.log","type":"unstyled","key":"9jimo"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Oct 3 17:53:26 vm22433 racoon: INFO: IPsec-SA request for 10.0.255.1 queued due to no phase1 found.\nOct 3 17:53:26 vm22433 racoon: INFO: initiate new phase 1 negotiation: 10.0.1.1[500]<=>10.0.255.1[500]\nOct 3 17:53:26 vm22433 racoon: INFO: begin Identity Protection mode.\nOct 3 17:53:26 vm22433 racoon: INFO: received Vendor ID: CISCO-UNITY\nOct 3 17:53:26 vm22433 racoon: INFO: received Vendor ID: DPD\nOct 3 17:53:26 vm22433 racoon: INFO: received Vendor ID: draft-ietf-ipsra-isakmp-xauth-06.txt\nOct 3 17:53:26 vm22433 racoon: INFO: ISAKMP-SA established 10.0.1.1[500]-10.0.255.1[500] spi:ebddc300af62ae42:abcdef0123\nOct 3 17:53:27 vm22433 racoon: INFO: initiate new phase 2 negotiation: 10.0.1.1[500]<=>10.0.255.1[500]\nOct 3 17:53:27 vm22433 racoon: INFO: received RESPONDER-LIFETIME: 4608000 kbytes\nOct 3 17:53:27 vm22433 racoon: WARNING: attribute has been modified.\nOct 3 17:53:27 vm22433 racoon: INFO: IPsec-SA established: ESP/Tunnel 10.0.1.1[500]->10.0.255.1[500] spi=238677(0xe39eabc)\nOct 3 17:53:27 vm22433 racoon: INFO: IPsec-SA established: ESP/Tunnel 10.0.1.1[500]->10.0.255.1500] spi=7204011111(0x44b4aaa)","type":"unstyled","key":"j8nc"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Вот и все. Остается добавить все необходимые манипуляции в автозагрузку, и можно начинать интеграцию приложений.","type":"unstyled","key":"39n6j"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"","type":"unstyled","key":"8fujv"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"","type":"marker","key":"36jJkwwJ1hB4uhDnxqWR"}],"entityMap":{"0":{"data":{"url":"https://en.wikipedia.org/wiki/List_of_IP_protocol_numbers"},"mutability":"MUTABLE","type":"LINK"},"1":{"data":{"url":"http://www.shorewall.net/IPSEC-2.6.html"},"mutability":"MUTABLE","type":"LINK"},"2":{"data":{"url":"http://manpages.ubuntu.com/manpages/xenial/man5/racoon.conf.5.html"},"mutability":"MUTABLE","type":"LINK"},"3":{"data":{"url":"http://manpages.ubuntu.com/manpages/trusty/man8/setkey.8.html"},"mutability":"MUTABLE","type":"LINK"},"4":{"data":{"url":"http://man7.org/linux/man-pages/man8/ip-xfrm.8.html"},"mutability":"MUTABLE","type":"LINK"}}},"mentions":[]}