Комментарии 15

Наконец-то годная статья. Но, как мне кажется, WireGuard для таких целей будет проще в использовании (если он работает на роутерах микротика).

На RouterOS пока нет поддержки WireGuard. Есть статья, где описан вариант с использованием на mikrotik OpenWRT, но не на всех моделях такое возможно.
Для микротиков с наличием аппаратной поддержки шифрования — IPsec всё-же «по интересней» в плане производительности.

Для линукса мне кажется вы не правильные IP для туннеля написали. Ну и почему racoon, а не strongswan?

На стороне линукса:
# Создаем интерфейс
sudo ip tunnel add ipip-ipsec0 local 192.168.255.1 remote 192.168.255.2 mode ipip


При этом со стороны микротика:
Local Address 192.168.0.2
Remote Address 192.168.0.1


Ну и для ipsec на стороне микротика в policy задана сеть:
Src. Address 192.168.0.0/30
Dest. Address 192.168.0.0/30


Однако линукс показывает:
sudo ip xfrm policy

src 192.168.255.0/30 dst 192.168.255.0/30
Большое спасибо за статью. Предельно четко и доступно.
Получилоось все на 98% ;)
Ipsec поднялся, все четко «racoon: INFO: ISAKMP-SA established»
Но ip xfrm policy показывает на всё нули- «src 0.0.0.0/0 dst 0.0.0.0/0»
А в Mikrotik, интерфейс IPIP-IPsec0 — скачет Up / Down ежесекундно.
В логах Mikrotik в debug режиме видно, что route назначается и потом сразу удааляется. Больше никаких ошибок.
Подскажите, пожалуйста, куда копать?
После ISAKMP-SA established
Начинается вторая фаза: INFO: respond new phase 2 negotiation:
INFO: Update the generated policy:
INFO: Adjusting my encmode UDP-Tunnel->Tunnel
INFO: Adjusting peer's encmode UDP-Tunnel(3)->Tunnel(1)
Если все успешно, поднимаются esp туннели: INFO: IPsec-SA established: ESP/Tunnel
Если нет, то будут выведены ошибки по причине которых IPsec-SA не установился.

На микротике, в разделе IPsec, есть вкладка Installed SA's — тут отображаются установленные esp туннели. На вкладке Policies, у нашей политики, в колонке PH2 State, должно быть established.
Добрый день! У меня похожая конфигурация: Mikrotik SXT-LTE Kit за NAT провайдера и сервер CentOS с белым IP. IPSec поднялся, о чем свидетельствуют записи в логах на сервере:
INFO: ISAKMP-SA established 62.109.**.**[4500]-81.30.**.**[5569]
INFO: respond new phase 2 negotiation: 62.109.**.**[4500]<=>81.30.**.**[5569]
INFO: Update the generated policy : 192.168.22.0/30[0] 192.168.22.0/30[0]
INFO: Adjusting my encmode UDP-Tunnel->Tunnel
INFO: Adjusting peer's encmode UDP-Tunnel(3)->Tunnel(1)
INFO: IPsec-SA established: ESP/Tunnel 62.109.**.**[4500]->81.30.**.*[5569]
INFO: IPsec-SA established: ESP/Tunnel 62.109.**.**[4500]->81.30.**.*[5569]

Со стороны микротика PH2 State также показывает established.
Проблема заключается в том — никак не могу заставить ходить трафик м/ду IPIP-интерфейсами. IP-адреса назначены, маршруты прописаны, с iptables то-же все в порядке.
При отправке ICMP со стороны микрота, на сервере tcpdump показывает следующее:
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
11:22:49.938437 IP 192.168.22.2 > 192.168.22.1: ICMP echo request, id 565, seq 0, length 36
11:22:50.938368 IP 192.168.22.2 > 192.168.22.1: ICMP echo request, id 565, seq 1, length 36

Причем, данная активность отображается при прослушивании eth0 — это интерфейс с белым IP. Куда уже копать, даже не представляю, но все-же кажется, что то-то не так с политиками IPSec?
Проверьте микротик. В настройках nat проверьте, что исключен трафик ipsec (в advanced-ipsec policy: out-none). В fierwall если есть общее блокирующее правило, то для трафика ipsec-подсети нужно добавить разрешающее правило (если делали nat на ipip интерфейсе, то не обязательно).
Да, я добавил правило в цепочку srcnat, как написано в статье:
chain=srcnat action=masquerade out-interface=lte1 log=no log-prefix="" ipsec-policy=out,none
Общие правила блокировки трафика на время теста вообще отключил.
Такой вопрос: можно ли применить настроенную таким образом политику IPSec для L2TP соединения вместо IPIP?
Посмотрите в разделе ipsec Active Peers и InstalledSAs — там выводится информация о пирах, установленных туннелях и статистика по приему\передачи пакетов.
Запустите traceroute и проверьте, что пакеты уходят именно в туннель (статистика по приему\передачи пакетов должна синхронно меняться с отправкой traceroute/ping пакетов).
В настройках логирования добавьте вывод лога ipsec: System-Logging-Rules: ipsec, Action: memory.
Так же проверьте, что сам интерфейс IPIP активен. На стороне линукса тоже нужно выполнить проверки.

Вы можете использовать любой виртуальный L3 интерфейс который поддерживается вашими хостами. IPIP имеет малый оверхед, если нет необходимости гонять мультикаст, использовать динамический роутинг и т.д. то его более чем достаточно.
Так и не удалось найти причину, по которой отсутствовал обмен трафиком м/ду IPIP-интерфейсами. Решение — пришлось обновить версию OS на сервере с CentOS release 6.10 (Final) до CentOS Linux release 7.8.2003 (Core). После обновления сразу все заработало — даже ничего не пришлось менять в конфигах iptables и racoon.
Буду очень благодарен, если кто-то подскажет, с чем это может быть связано?
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.