Comments 15
UFO just landed and posted this here
На RouterOS пока нет поддержки WireGuard. Есть статья, где описан вариант с использованием на mikrotik OpenWRT, но не на всех моделях такое возможно.
Для микротиков с наличием аппаратной поддержки шифрования — IPsec всё-же «по интересней» в плане производительности.
Для линукса мне кажется вы не правильные IP для туннеля написали. Ну и почему racoon, а не strongswan?
Что именно неправильно с ip адресами?
На стороне линукса:
При этом со стороны микротика:
Ну и для ipsec на стороне микротика в policy задана сеть:
Однако линукс показывает:
# Создаем интерфейс
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 назначается и потом сразу удааляется. Больше никаких ошибок.
Подскажите, пожалуйста, куда копать?
Получилоось все на 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.
Начинается вторая фаза: 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 поднялся, о чем свидетельствуют записи в логах на сервере:
Со стороны микротика PH2 State также показывает established.
Проблема заключается в том — никак не могу заставить ходить трафик м/ду IPIP-интерфейсами. IP-адреса назначены, маршруты прописаны, с iptables то-же все в порядке.
При отправке ICMP со стороны микрота, на сервере tcpdump показывает следующее:
Причем, данная активность отображается при прослушивании eth0 — это интерфейс с белым 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?
Да, я добавил правило в цепочку srcnat, как написано в статье:
Общие правила блокировки трафика на время теста вообще отключил.
Такой вопрос: можно ли применить настроенную таким образом политику IPSec для L2TP соединения вместо IPIP?
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 имеет малый оверхед, если нет необходимости гонять мультикаст, использовать динамический роутинг и т.д. то его более чем достаточно.
Запустите 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.
Буду очень благодарен, если кто-то подскажет, с чем это может быть связано?
Буду очень благодарен, если кто-то подскажет, с чем это может быть связано?
Sign up to leave a comment.
IPIP IPsec VPN туннель между Linux машиной и Mikrotik за NAT провайдера