Подводные туннели и безопасность

Штош, с чистой совестью и спокойной душой можно рассказать новую эпопею по уже завершённой задаче с подключением к провайдеру через древние технологии.

Всё началось полгода назад, когда провайдер сообщил нам, что для взаимодействия с ним потребуется настроить ни много, ни мало – несколько IPSec туннелей, которые позволят поверх интернета “безопасно” обмениваться траффиком с ними. У меня под рукой была прекрасная железка Juniper SRX380, которая по всем параметрам должна была справиться с задачей и спокойно принять на себя весь удар шифрования траффика, но, как это часто бывает, что-то пошло не совсем по плану и мы потратили огромное количество времени чтобы понять что же.

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

По сути IPSec (IP Security) это достаточно старая реализация VPN туннелей, которая позволяет организовывать частные виртуальные сети поверх публичных и в траффик которых никто кроме соединившихся сторон не должен иметь возможности заглянуть. Для организации данных туннелей производятся всевозможные числодробления, зашифровки, расшифровки, в общем куча всякой математики, к которой предрасположено сетевое оборудование. Но как это часто бывает – каждый производитель этого самого сетевого оборудования видит стандарты по-своему, откуда возникает множество проблем. Есть возможность настроить туннель в двух режимах – policy-based (когда траффик, выходящий из определённого интерфейса, внутри железки по определённым параметрам будет выбираться, шифроваться и дальше передаваться куда шёл) и route-based (когда в устройстве есть виртуальный интерфейс с какой-то адресацией и весь траффик, проходящий через этот интерфейс, независимо от параметров, шифруется и отправляется к строго указанной дестинации) По очевидным причинам разные режимы подходят для разных методов использования – в основном через ipsec туннели можно передавать IP траффик, а остальные протоколы могут работать, а могут не работать, но и тут ребята не растерялись и придумали, что внутри вот этого вот ipsec туннеля можно запустить ещё один протокол, под названием GRE, который уже может спокойно обслуживать любые протоколы, обходя ограничения чистого ipsec. Так вот, для обычного траффика TCP/IP вполне достаточно использовать route-based ipsec, всякие bgp, icmp и прочие нормально в него пролазят, однако для того, чтобы засунуть GRE нужно использовать policy-based ipsec, посколько партнёры на той стороне решили, что и сам ipsec туннель и gre интерфейс должны утилизировать одну и туж е связку source-destination. Т.е. по сути весь траффик, который уходит в GRE туннель сначала должен упаковываться в GRE, а уже потом шифроваться на ipsec и отправляться на ту сторону.

Суть да дело – начал я погружаться в это. основные туннели были подняты примерно в тот же день без каких-либо проблем (впрочем проблемы были, поскольку для апстрима у нас используется отдельный виртуальный роутер, но там быстро всё порешалось. Вкрации – для того, чтобы ipsec туннель нормально работал – его внешний интерфейс – адрес, на который терменируется ipsec – должен находиться в том же виртуальном инстансе, что и внешний интерфейс, в который выходит траффик до партнёра), а вот с GRE over IPsec возникли проблемы. Продолжительный гуглёж и игрища на стенде ничего не дали, пока я не обнаружил на просторах интернета, что у Juniper SRX есть органичение – GRE over IPSec возможно запустить только с route-based IPSec. Запрос на использование route-base IPSec со стороны партнёра был отклонён со словами – всю жизнь так паркуемся, ради вас менять ничего не будем.

По советам проверенных комрадов было решено взять циску, во избежание каких-либо неточностей между разными производителями оборудования. Сказано – сделао, за гроши приобретене Cisco ASA 5508-X, всё настроено, но беда подкралась откуда не ждали – ASA, как впоследствии оказалось, не умеет в этот самый GRE. Т.е. все ipsec туннели успешно завелись, но соединиться так и не удалось.

В конечном итоге было принято решение перестать пытаться поженить сетевое оборудование и прямо на сервере было развёрнуто решение strongswan+bird, которое после непродолжительных приседаний и бесконечного гуглежа было-таки приведено в рабочее состояние. Правда пришлось дополнительно поприседать с policy-based routing. Зато мы узнали много нового, как то:

Рабочий конфиг для route-based ipsec получился таким

conn route-based
  left=1.2.3.4
  leftsubnet=0.0.0.0/0
  right=4.3.2.1
  rightsubnet=0.0.0.0/0
  type=tunnel
  keyexchange=ikev1
  auto=route
  authby=secret
  ike=aes256-sha1-modp1024
  esp=aes256-sha1
  lifetime=24h
  lifetime=1h
  mark=10

После того как в ipsec status подключение будет успешно установлено можно создавать интерфейс

ip tunnel add rb1 mode vti local 1.2.3.4 remote 4.3.2.1 key 10
ip link set up rb1
ip a add 10.0.0.2/31 dev rb1

и о чудо – ping 10.0.0.3 успешно проходит, bgp сеесия успешно устанавливается и все полученные с той стороны сети нормально работают. Тут ещё предлагают в интернете подкручивать sysctl -w net.ipv4.conf.rb1.disable\_policy=1, но у меня без этого заработало, впрочем стоит иметь в виду.

Попутно для route-based ipsec в интернете советуют настраивать /etc/strongswan.d/charon.conf

install_routes = no
install_virtual_ip = no

В свою очередь для GRE over IPSec процесс немного иной. Подключение выглядит проще

conn grx
  left 1.2.3.4
  right 4.3.2.2
  type=tunnel
  keyexchange=ikev1
  auto=add
  authby=secret
  ike=3des-sha1-modp1024
  esp=3des-sha1
  ikelifetime=24h
  lifetime=1h

А сам GRE туннель уже поверх этого накорячивается следующим образом

ip tunnel add grx mode gre local 1.2.3.4 remote 4.3.2.2
ip link set up grx
ip a add 10.0.0.4/31 dev grx

И вот уже GRE over IPSec работает как задумано.

Очевидно ещё нужно настроть /etc/ipsec.secret, но тут уже вы сами с усами. Эндой ёр трип.