Mikrotik.moscow [тема: VPN с GCP]

VPN с GCP

Mon, 29 Jun 2020 12:45:00 -0400

VPN с GCP RouterOS в форуме RouterOS.
Окей, чтобы внести ясность в то, что сейчас происходит.

/ip ipsec policy
add action=none dst-address=10.99.6.0/24 src-address=0.0.0.0/0
add action=none dst-address=10.0.0.0/13 src-address=0.0.0.0/0
set 2 proposal=GCP_phase2
add dst-address=169.254.1.2/32 peer=ike-gcp_casino proposal=GCP_phase2 sa-dst-address=35.204.xx.xx sa-src-address=94.237.xx.xx src-address=169.254.1.1/32 tunnel=yes

Вот что я добавил.

[konrad@MikroTik] /ip ipsec identity> ..policy pr
Flags: T - шаблон, X - отключено, D - динамический, I - недействительный, A - активный, * - по умолчанию
# PEER TUNNEL SRC-ADDRESS DST-ADDRESS PROTOCOL ACTION LEVEL PH2-COUNT
0 0.0.0.0/0 10.99.6.0/24 all none
1 0.0.0.0/0 10.0.0.0/13 all none
2 T * ::/0 ::/0 all
3 A ike-gcp_casino yes 169.254.1.1/32 169.254.1.2/32 all encrypt require 1
4 DA ike-gcp_casino yes 0.0.0.0/0 35.204.xx.xx/32 all encrypt unique 1

Мне пришлось добавить BGP вот так, чтобы установить соединения (Received entries 3 ADb 10.101.0.0/16 169.254.1.2 20), но когда хочу пропинговать, например, с 10.99.6.2 (который — Mikrotik) хост в GCP 10.101.13.250, получаю таймаут.

[konrad@MikroTik] /ip ipsec identity> /tool traceroute address=10.101.13.250
# ADDRESS LOSS SENT LAST AVG BEST WORST STD-DEV STATUS
1 94.237.xx.xx 66.. 31 0ms 197.6 0 988.7 395.2 host unreachable from 94.237.xx.xx

Я думаю, что без ipsec policy трафик не пройдёт через туннель, так же как BGP не прошёл... И это то, чего мы не можем позволить, ведь именно поэтому пытаемся протолкнуть 0.0.0.0/0 <=> 0.0.0.0/0.

И наконец отвечая на ваши вопросы:
Да, туннель поднят.

Flags: H - hw-aead, A - AH, E - ESP
0 E spi=0x1D64599 src-address=35.204.xx.xx dst-address=94.237.xx.xx state=mature auth-algorithm=sha256 enc-algorithm=aes-cbc enc-key-size=256 auth-key=“f36938f75178530fa65600cabde1015f9ca9733e9e7f8158910f0a2fb60cbb46” enc-key=“71a695dd8e04c2117c1f672c1386ab237791ead7e596b7fbff79a6aa26f5b71d” addtime=jun/29/2020 14:36:21 expires-in=1h10m22s add-lifetime=2h24m19s/3h24s current-bytes=189600 current-packets=3160 replay=128
1 E spi=0xD1C79D38 src-address=94.237.xx.xx dst-address=35.204.xx.xx state=mature auth-algorithm=sha256 enc-algorithm=aes-cbc enc-key-size=256 auth-key=“f38ced110cb246b66eeab648b2cafe709a4f215a4ee46d47dabab3d9f346ea9f” enc-key=“85205ae97a803ec5f1f6a29316d83e533c7009d37e6232d40ca4ca1d456ff26e” add-lifetime=2h24m19s/3h24s replay=128
2 E spi=0x93CFCD7 src-address=35.204.xx.xx dst-address=94.237.xx.xx state=mature auth-algorithm=sha256 enc-algorithm=aes-cbc enc-key-size=256 auth-key=“0408aac30d5f47d8122e18ce59c51610883c47f9c0205a5324736280a206545c” enc-key=“e25b17c33ecf846ff3ea40bfa5e44d2dce5418731bbbfb111f670b3e2475463f” addtime=jun/29/2020 15:02:52 expires-in=1h36m57s add-lifetime=2h24m22s/3h28s current-bytes=489017 current-packets=5964 replay=128
3 E spi=0x2013652C src-address=94.237.xx.xx dst-address=35.204.xx.xx state=mature auth-algorithm=sha256 enc-algorithm=aes-cbc enc-key-size=256 auth-key=“bbe1a9483bd32acc69c10453541ed253c8c265305c2bdd064510badb4c4afc10” enc-key=“3e09b65774d4c95ffa8ffdf0e4ed615aedd2512c78b0291916837c53d15ca1a8” addtime=jun/29/2020 15:02:52 expires-in=1h36m57s add-lifetime=2h24m22s/3h28s current-bytes=35991 current-packets=574 replay=128
29.06.2020 12:45:00, eset.

VPN с GCP

Mon, 29 Jun 2020 11:58:00 -0400

VPN с GCP RouterOS в форуме RouterOS.
Так ты хочешь сказать, что теперь у тебя есть работающий туннель, то есть установленный SA, созданный из шаблона?
29.06.2020 11:58:00, sindy.

VPN с GCP

Mon, 29 Jun 2020 09:05:00 -0400

VPN с GCP RouterOS в форуме RouterOS.
Да, но, как видишь, разобраться почему не получается. Таймауты исчезли, но теперь проблемы с режимом, и ещё при настройке режима (my-id в fqdn) возникает ситуация:

[konrad@MikroTik] /ip ipsec policy> ..identity pr
Flags: D - динамический, X - отключён
0 peer=ike-gcp_casino auth-method=pre-shared-key my-id=fqdn:94.237.xx.xx secret=“xxxx” generate-policy=port-override

12:08:39 ipsec → ike2 ответ, обмен: AUTH:1 35.204.xx.xx[4500]
12:08:39 ipsec payload зафиксирован: ENC (48 байт)
12:08:39 ipsec обрабатывается payload: ENC
12:08:39 ipsec,debug => iv (размер 0x10)
12:08:39 ipsec,debug a0028764 00a8d9d7 669c6e9f e13afa7b
12:08:39 ipsec,debug => открытый payload (усечён) (размер 0x8)
12:08:39 ipsec,debug 00000008 00000018
12:08:39 ipsec,debug расшифрован
12:08:39 ipsec payload зафиксирован: NOTIFY (8 байт)
12:08:39 ipsec обрабатываются payload: NOTIFY
12:08:39 ipsec уведомление: AUTHENTICATION_FAILED
12:08:39 ipsec,error получена критическая ошибка: AUTHENTICATION_FAILED

Или мне стоит задать новый шаблон?
GCP отправляет insertId: “c7lbfvg25fd285” labels: {…} logName: “projects/casino-front/logs/cloud.googleapis.com%2Fipsec_events” receiveTimestamp: “2020-06-29T09:24:10.998457933Z” resource: {…} severity: “DEBUG” textPayload: “generating IKE_AUTH response 1 [ N(AUTH_FAILED) ]” timestamp: “2020-06-29T09:24:10.972873297Z”

@sindy Я без понятия, почему перестало работать.

Окей, проблема была в фаерволе. Раньше в raw цепочке фаервола были какие-то prerouting записи, которые я удалил. И вот не понимаю, почему они не добавляются снова, хотя я прописываю:

/ip ipsec identity add generate-policy=port-strict notrack-chain=prerouting peer=ike-gcp_casino secret=xxxx notrack-chain=prerouting

Что теперь делать с BGP?
29.06.2020 09:05:00, eset.

VPN с GCP

Mon, 29 Jun 2020 07:55:00 -0400

VPN с GCP RouterOS в форуме RouterOS.
Тебе понадобится подробный лог IPsec, чтобы понять, почему туннель не поднимается. Отключи подробное логирование на пирах:

/system logging add topics=ipsec,!packet

Начни копировать лог в отдельный файл:

/log print follow-only file=ipsec-startup where topics~“ipsec”

Включи пира. Подожди, пока соединение не упадёт. Прерви команду /log print … Скачай файл и проанализируй его.
29.06.2020 07:55:00, sindy.

VPN с GCP

Mon, 29 Jun 2020 07:22:00 -0400

VPN с GCP RouterOS в форуме RouterOS.
Окей, в целом меня беспокоят две вещи. Я настроил это так (чтобы исключить два диапазона IP-адресов: 10.x и 172.16-31)

/ip ipsec policy set 0 disabled=yes
add action=none dst-address=10.99.6.0/24 src-address=0.0.0.0/0
add action=none dst-address=10.0.0.0/13 src-address=0.0.0.0/0
add dst-address=0.0.0.0/0 proposal=GCP_phase2 src-address=0.0.0.0/0 template=yes

Но туннель не подключается:
10:19:52 ipsec,info new ike2 SA (I): 94.237.xx.xx[4500]-35.204.xx.xx[4500] spi:9df288f54d6e746b:0d8da2bdab6b7d67
10:19:52 ipsec,info,account peer authorized: 94.237.xx.xx[4500]-35.204.xx.xx[4500] spi:9df288f54d6e746b:0d8da2bdab6b7d67
10:19:52 ipsec,info killing ike2 SA: 94.237.xx.xx[4500]-35.204.xx.xx[4500] spi:9df288f54d6e746b:0d8da2bdab6b7d67

У меня хотя бы один раз получилось заставить это работать, но я не помню, что именно я делал.
29.06.2020 07:22:00, eset.

VPN с GCP

Sun, 28 Jun 2020 09:24:00 -0400

VPN с GCP RouterOS в форуме RouterOS.
Над этим был пронумерованный список групп/типов/категорий подсетей назначения. Так что «первый тип» означает «те, что локальные для сайта GCP». В этом посте есть упрощённый пример. Если идея всё ещё не ясна: представьте, что у вас есть две подсети на стороне GCP — 172.16.3.0/24 и 172.16.8.0/24, а ваши локальные подсети — 172.16.5.0/24 и 172.16.71.0/24, и вам вообще всё равно на интернет-адреса. В диапазоне 172.16.0.0/16 всего 256 подсетей /24, и нужно исключить всего две из них от совпадения с политикой «any=>any», потому что остальные, которые не локальные ни для Mikrotik, ни для GCP, никогда не используются (если только у вас не более сложная топология внутренней сети). Для этого случая, не учитывая интернет, достаточно следующих «исключающих политик»:

/ip ipsec policy add action=none dst-address=172.16.5.0/24 src-address=0.0.0.0/0
add action=none dst-address=172.16.71.0/24 src-address=0.0.0.0/0
add action=encrypt dst-address=0.0.0.0/0 src-address=0.0.0.0/0

Если же нужно, чтобы хосты из этих двух локальных подсетей могли выходить в интернет, понадобятся дополнительные политики с action=none, покрывающие все публичные адресные диапазоны, например:

dst-address=0.0.0.0/1 (0.0.0.0–127.255.255.255) (кстати, сюда входят и 0.0.0.0/8, 10.0.0.0/8 и 127.0.0.0/8 — это не публичные адреса, но неважно, поскольку мы не хотим, чтобы политика «any=>any» для IPsec попадала на них)
dst-address=128.0.0.0/3 (128.0.0.0–159.255.255.255)
dst-address=160.0.0.0/5 (160.0.0.0–167.255.255.255)
dst-address=168.0.0.0/6 (168.0.0.0–171.255.255.255)
dst-address=172.0.0.0/12 (172.0.0.0–172.15.255.255) <— здесь как раз «пробел» для приватного диапазона 172.16.0.0/12 (172.16.0.0–172.31.255.255) —>
dst-address=172.32.0.0/11 (172.32.0.0–172.63.255.255)
dst-address=172.64.0.0/10 (172.64.0.0–172.127.255.255)
dst-address=172.128.0.0/9 (172.128.0.0–172.255.255.255)
dst-address=173.0.0.0/8 (173.0.0.0–173.255.255.255)
dst-address=174.0.0.0/7 (174.0.0.0–175.255.255.255)
dst-address=176.0.0.0/4 (176.0.0.0–191.255.255.255)
dst-address=192.0.0.0/2 (192.0.0.0–255.255.255.255) (как выше, неважно, что 192.168.0.0/16 — не публичный диапазон, ведь и так мы защищаем его в IPsec)

Если не понятно, почему это выглядит именно так, возможно вы просто не до конца понимаете принцип работы маски подсети. Например, диапазон от 128.0.0.0 до 191.255.255.255 можно записать как 128.0.0.0/2, потому что первые два бита самого старшего октета должны быть 10, а остальные — любые. Старший октет тогда может принимать значения от 10000000 (0x80, 128) до 10111111 (0xbf, 191). Если вы хотите при этом исключить 168.0.0.0/5 (то есть 168.0.0.0–175.255.255.255), придётся разбить этот диапазон на несколько частей. Вместо того чтобы писать восемь отдельных /5 в пределах /2, их можно сгруппировать так, где это возможно:

128/5 \
> 128/4 \
136/5 / \
> 128/3
144/5 \ /
> 144/4 /
152/5 /

160/5

(168/5)

176/5 \
> 176/4
184/5 /

В итоге у вас получается 128/3, 160/5 и 176/4 как исключения из полного 128/2, и только 168/5 не покрывается ни одним из этих диапазонов.
28.06.2020 09:24:00, sindy.

VPN с GCP

Sat, 27 Jun 2020 23:11:00 -0400

VPN с GCP RouterOS в форуме RouterOS.
Что ты имеешь в виду под «первым типом»? Я буквально изучал твой ответ, но без практического примера трудно понять. Буду очень благодарен, если ты сможешь показать примеры.
27.06.2020 23:11:00, eset.

VPN с GCP

Sun, 21 Jun 2020 10:04:00 -0400

VPN с GCP RouterOS в форуме RouterOS.
Как уже говорил @emils, RouterOS сейчас не поддерживает виртуальные интерфейсы для IPsec. Я не уверен, сможет ли BGP работать с пиром, к которому нет доступа через конкретный интерфейс, но если такое ограничение есть, возможно, его можно обойти с помощью выделённого мостового интерфейса без портов — правда, я этого никогда не пробовал. Помимо этого, вся проблема отсутствия функционала виртуального интерфейса в том, что политика IPsec всегда имеет приоритет над обычным маршрутизированием, тогда как удалённый пир требует селектор трафика any->any; селектор трафика политики используется не только локально, но и согласуется через IKE или IKEv2, и нельзя использовать один селектор для согласования, а другой — для выбора трафика. Поэтому чтобы выполнить требование удалённого пира, нам нужно «спрятать» всё, что не хотим отправлять через IPsec-туннель к этому пиру, с помощью других политик (к тому же нельзя иметь больше одного такого пира, так как две одинаковые политики не поддерживаются).

Итак, у вас три группы сетей назначения:

- те, что локальны для сайта GCP
- те, что локальны для Mikrotik
- остальная часть диапазона 0.0.0.0 .. 255.255.255.255

Нужно, чтобы пакеты ко всем адресам, кроме первых, попадали под действие какой-то другой политики с соответствующим селектором трафика до того, как их «поймает» политика 0.0.0.0/0 => 0.0.0.0/0. Исключить локальные подсети относительно просто, но вот подобрать все сети кроме первой группы — это головная боль, особенно если таких подсетей несколько.

Если маршрутизатор не используется для доступа в интернет, можно заботиться только о второй группе, используя политики с действием action=none, а остальное «чернолысить» в обычном маршрутизировании (пакеты к чернолысим адресам не доходят до сопоставления с селекторами трафика). Если же маршрутизатор используется для интернета, придётся строить полный набор политик, которые покрывают всё, кроме первой группы.

В вашем примере вы настроили исключающие политики с адресатами 0.0.0.0/1 и 128.0.0.0/1, которые накрывают весь диапазон 0.0.0.0/0, поэтому ничего не доходит до политики с адресатом 0.0.0.0/0. В качестве эксперимента можно настроить исключающие политики только для локальных подсетей, отключить маршрут по умолчанию в обычном маршрутизировании и добавить только маршруты до публичного IP GCP (чтобы туннель мог установиться) и до IP, на котором слушает BGP-инстанс GCP.

В такой настройке установление туннеля не выбросит вас из управления маршрутизатором, и будет возможно пингануть через IPsec-туннель. Только когда это заработает стабильно, имеет смысл настраивать BGP и дополнительные исключающие маршруты и политики.

Если ваш Mikrotik достаточно мощный и поддерживает функционал Metarouter, гораздо проще использовать один экземпляр RouterOS с описанными настройками, эффективно имитируя функциональность виртуального интерфейса IPsec, а BGP и остальное маршрутизирование запускать на базовом экземпляре. Если нет, то сложность создания исключающих политик зависит от количества подсетей на стороне GCP и от того, статичны они или меняются со временем — в последнем случае исключающие политики придётся генерировать сложным скриптом на основе маршрутов, получаемых через BGP.
21.06.2020 10:04:00, sindy.

VPN с GCP

Sat, 20 Jun 2020 23:57:00 -0400

VPN с GCP RouterOS в форуме RouterOS.
@sindy Единственное, что у меня получается — это сделать это с помощью шаблона: взять фото и превратить в гифку.
20.06.2020 23:57:00, eset.

VPN с GCP

Mon, 29 Jun 2020 08:41:00 -0400

VPN с GCP RouterOS в форуме RouterOS.
Сообщение «ipsec,info,account peer authorized», которое вы публиковали ранее, отсутствует в этом логе, поэтому ошибка с таймаутом тут связана с другой проблемой, не такой, как в предыдущем случае.
29.06.2020 08:41:00, sindy.

VPN с GCP

Mon, 29 Jun 2020 08:31:00 -0400

VPN с GCP RouterOS в форуме RouterOS.
Должен сказать, что логи особо не дают информации, кроме того, что происходит таймаут.

29 июня 2020, 11:27:13 — RouterOS 6.45.9 software id
11:27:17 — ipsec ike2 init повторная отправка
11:27:17 — ipsec, debug ===== отправка 424 байт с 94.237.xx.xx[4500] на 35.204.xx.xx[4500]
11:27:17 — ipsec, debug будет отправлено 1 сообщение по 428 байт на 35.204.xx.xx[4500]
11:27:22 — ipsec ike2 init повторная отправка
11:27:22 — ipsec, debug ===== отправка 424 байт с 94.237.xx.xx[4500] на 35.204.xx.xx[4500]
11:27:22 — ipsec, debug будет отправлено 1 сообщение по 428 байт на 35.204.xx.xx[4500]
11:27:27 — ipsec ike2 init повторная отправка
11:27:27 — ipsec, debug ===== отправка 424 байт с 94.237.xx.xx[4500] на 35.204.xx.xx[4500]
11:27:27 — ipsec, debug будет отправлено 1 сообщение по 428 байт на 35.204.xx.xx[4500]
11:27:32 — ipsec ike2 init таймаут
11:27:40 — ipsec ike2 стартует для: 35.204.xx.xx
11:27:40 — ipsec добавляет notify: NAT_DETECTION_DESTINATION_IP
11:27:40 — ipsec, debug => (размер 0x1c)
11:27:40 — ipsec добавляет notify: NAT_DETECTION_SOURCE_IP
11:27:40 — ipsec, debug => (размер 0x1c)
11:27:40 — ipsec добавляет payload: NONCE
11:27:40 — ipsec, debug => (размер 0x1c)
11:27:40 — ipsec добавляет payload: KE
11:27:40 — ipsec, debug => (первые 0x100 из 0x108)
11:27:40 — ipsec добавляет payload: SA
11:27:40 — ipsec, debug => (размер 0x30)
11:27:40 — ipsec ← ike2 запрос, обмен: SA_INIT:0 35.204.xx.xx[4500]
11:27:40 — ipsec, debug ===== отправка 424 байт с 94.237.xx.xx[4500] на 35.204.xx.xx[4500]
11:27:40 — ipsec, debug будет отправлено 1 сообщение по 428 байт на 35.204.xx.xx[4500]
11:27:47 — ipsec ike2 init повторная отправка
11:27:47 — ipsec, debug ===== отправка 424 байт с 94.237.xx.xx[4500] на 35.204.xx.xx[4500]
11:27:47 — ipsec, debug будет отправлено 1 сообщение по 428 байт на 35.204.xx.xx[4500]
11:27:52 — ipsec ike2 init повторная отправка
11:27:52 — ipsec, debug ===== отправка 424 байт с 94.237.xx.xx[4500] на 35.204.xx.xx[4500]
11:27:52 — ipsec, debug будет отправлено 1 сообщение по 428 байт на 35.204.xx.xx[4500]
11:27:57 — ipsec ike2 init повторная отправка
11:27:57 — ipsec, debug ===== отправка 424 байт с 94.237.xx.xx[4500] на 35.204.xx.xx[4500]
11:27:57 — ipsec, debug будет отправлено 1 сообщение по 428 байт на 35.204.xx.xx[4500]
11:28:02 — ipsec ike2 init таймаут
11:28:10 — ipsec ike2 стартует для: 35.204.xx.xx
11:28:10 — ipsec добавляет notify: NAT_DETECTION_DESTINATION_IP
11:28:10 — ipsec, debug => (размер 0x1c)
11:28:10 — ipsec добавляет notify: NAT_DETECTION_SOURCE_IP
11:28:10 — ipsec, debug => (размер 0x1c)
11:28:10 — ipsec добавляет payload: NONCE
11:28:10 — ipsec, debug => (размер 0x1c)
11:28:10 — ipsec добавляет payload: KE
11:28:10 — ipsec, debug => (первые 0x100 из 0x108)
11:28:10 — ipsec добавляет payload: SA
11:28:10 — ipsec, debug => (размер 0x30)
11:28:10 — ipsec ← ike2 запрос, обмен: SA_INIT:0 35.204.xx.xx[4500]
11:28:10 — ipsec, debug ===== отправка 424 байт с 94.237.xx.xx[4500] на 35.204.xx.xx[4500]
11:28:10 — ipsec, debug будет отправлено 1 сообщение по 428 байт на 35.204.xx.xx[4500]

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

11:40:02 — ipsec peer выбрал режим туннеля
11:40:02 — ipsec смена режима не поддерживается

И вот что я вижу.
29.06.2020 08:31:00, eset.

VPN с GCP

Tue, 02 Jun 2020 17:47:00 -0400

VPN с GCP RouterOS в форуме RouterOS.
Я собрал кучу информации в огромной документации GCP по настройке IPsec с использованием IKEv2 и BGP. Вот что я выяснил, и это важно: при использовании IKEv2 ваш VPN-шлюз-партнёр должен принимать все CIDR в каждом селекторе трафика через один Child SA. Не все VPN-шлюзы это поддерживают. VPN-шлюзы, которые создают отдельный Child SA для каждого CIDR, не совместимы с Cloud VPN. Подробнее о стратегиях выбора селекторов трафика можно почитать здесь: https://cloud.google.com/vpn/docs/concepts/choosing-networks-routing#ts-ip-ranges.

Кроме того, я столкнулся с проблемой — пинг до удалённых сетей не проходит. Подробнее об этой проблеме описано здесь: http://forum.mikrotik.com/t/ipsec-ikev2-gcp-ping-timeout/129598/8.

Несколько дней общался с поддержкой GCP, и они заметили, что у меня постоянно появляется такая запись:
{
insertId: "1hkfx2ag100glgy"
labels: {…}
logName: "projects/casino-front/logs/cloud.googleapis.com%2Fipsec_events"
receiveTimestamp: "2020-06-02T16:56:32.894395202Z"
resource: {…}
severity: "NOTICE"
textPayload: "Warning: Remote traffic selectors narrowed for Child SA: vpn_94.237.xx.xx. Configured TS: [0.0.0.0/0], negotiated TS: [172.16.18.0/24]. Please verify configuration on the remote side."
timestamp: "2020-06-02T16:56:32.831941608Z"
}

Короче, проблема в том, что я не могу использовать уникальный уровень, потому что GCP требует один Child для согласования SA. Я изменил настройку, но при этом нужно указать 0.0.0.0 в src и dst в IPsec-политике. А когда я это делаю, связь теряется.

Может, кто-то подскажет, как двигаться дальше?
02.06.2020 17:47:00, eset.