Назад | Перейти на главную страницу

VPN между локальной системой и GCP: общие маршруты, но пинг не проходит

Я боролся с настройкой VPN между локальной сетью и GCP более недели. На данный момент у меня совершенно нет идей, и я хотел бы получить помощь сетевых специалистов.

Цель

Конечная цель проста: заставить экземпляр виртуальной машины на GCP беспрепятственно взаимодействовать с виртуальной машиной на месте - но с двумя активными маршрутизаторами.
Настройка выглядит примерно так:

       GCP_VM                                                           OP_VM
    10.0.0.25                                                    10.100.0.200
            |                                                    |
            |                                           (DC Router Gateway)
            |                                               10.100.0.80
            |                                                    |
            └-- HA_VPN (AS65001) <==========> Router (AS65002) --┘

     Public IP: xx.xx.xx.xx                   yy.yy.yy.yy
     Advertise: 10.0.0.0/24 BGP               10.100.0.0/24 BGP
  VPN IP Range: 169.254.0.1/30                169.254.0.2 (as Peer)
    Private IP: NA                            10.100.0.50

Сложность здесь в том, что Router здесь напрямую не связан с OP_VM. Это локальная настройка, которую мы не контролируем. OP_VM получает свой IP 10.100.0.200 с какого-то другого роутера, а наш Router подключен к той же локальной сети. У нас есть только одна стойка в центре обработки данных, и нам нужно достичь OP_VM который размещен другой стороной (в другой стойке). Наша стойка ассоциируется с 10.100.0.50.

И с этим я хочу получить следующую работу:

me@GCP_VM:10.0.0.25:~$ ping 10.100.0.200

Текущее состояние

При описанной выше настройке VPN и BGP кажутся работоспособными из журналов с обеих сторон.

Из GCP_VM, Я могу пинговать 10.100.0.50 (Router) успешно.

me@GCP_VM:10.0.0.25:~$ ping 10.100.0.50
PING 10.100.0.50 (10.100.0.50) 56(84) bytes of data.
64 bytes from 10.100.0.50: icmp_seq=1 ttl=254 time=24.9 ms
...

Также из Router, Я могу подтвердить, что могу пинговать 10.100.0.200 (OP_VM). 

# With the Router setup of something like
#
#     ip route 10.100.0.0/24 gateway 10.100.0.80

root@Router:10.100.0.50:~$ ping 10.100.0.200
ping 10.100.0.200
received from 10.100.0.200: icmp_seq=0 ttl=63 time=0.583ms
received from 10.100.0.200: icmp_seq=1 ttl=63 time=0.571ms

2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max = 0.571/0.577/0.583 ms

Из GCP_VMоднако пинговать 10.100.0.200 (OP_VM) идет отсутствует.

# With the Router setup of something like
#
#     ip route 10.100.0.0/24 gateway 10.100.0.80

me@GCP_VM:10.0.0.25:~$ ping 10.100.0.200
PING 10.100.0.200 (10.100.0.200) 56(84) bytes of data.
^C
--- 10.100.0.200 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3051ms

Я, вероятно, неправильно понимаю настройку шлюза, но изменение маршрута, как показано ниже, дает мне другой результат:

# With the Router setup of something like
#
#     ip route 10.100.0.0/24 gateway 10.100.0.50
#                                             ~~ <- Router itself

me@GCP_VM:10.0.0.25:~$ ping 10.100.0.200
PING 10.100.0.200 (10.100.0.200) 56(84) bytes of data.
From 169.254.0.2 icmp_seq=7 Destination Host Unreachable
From 169.254.0.2 icmp_seq=6 Destination Host Unreachable
From 169.254.0.2 icmp_seq=5 Destination Host Unreachable
From 169.254.0.2 icmp_seq=4 Destination Host Unreachable
From 169.254.0.2 icmp_seq=3 Destination Host Unreachable
From 169.254.0.2 icmp_seq=2 Destination Host Unreachable
From 169.254.0.2 icmp_seq=1 Destination Host Unreachable
^C
--- 10.100.0.200 ping statistics ---
9 packets transmitted, 0 received, +7 errors, 100% packet loss, time 8141ms
pipe 7

При такой настройке шлюза Router больше не могу пинговать OP_VM. По крайней мере, мне кажется, что VPN установлен и IP анонсируется правильно. Но это не совсем правильно с точки зрения сети.

Вопросы

Я не думаю, что со стороны GCP еще много чего предстоит сделать, и, похоже, проблема заключается исключительно в локальной системе.

Есть ли какие-либо проблемы с настройкой или опасения, которые могут вызвать неправильное поведение VPN, BGP, ARP и т. Д.? Что может вызвать такой случай, когда кажется, что маршруты используются совместно, но на самом деле нет к ним доступа?

Прочие примечания

2019/12/21 16:35:40: LAN1 OUT:IP TCP 10.100.0.227:50516 > 10.103.24.1:80

Обновление (24 декабря)

я сделал tcpdump для простого пинга между GCP_VM и Router.

Из GCP_VM к Router (журналы из GCP_VM)

$ ping 10.100.0.50 > /dev/null &
$ sudo tcpdump -i eth0 | grep 10.100
...
18:49:18.696178 IP GCP_VM.(snip) > 10.100.0.50: ICMP echo request
, id 32396, seq 0, length 64
18:49:18.700395 IP 10.100.0.50 > GCP_VM.(snip): ICMP echo reply, 
id 32396, seq 0, length 64

Из Router к GCP_VM (журналы из GCP_VM)

# ping from Router, with `ping 10.0.0.25`
$ sudo tcpdump -i eth0 | grep 169.254
...
18:40:18.554555 IP 169.254.0.2 > GCP_VM.(snip): ICMP echo request,
 id 3369, seq 0, length 72
18:40:18.554586 IP GCP_VM.(snip) > 169.254.0.2: ICMP echo reply, i
d 3369, seq 0, length 72

Хотя tcpdump показывает, что ответ отправляется сюда, он никогда не получен Router.
Кроме того, пинг 169.254.0.2 из GCP_VM не получает ответа.

$ ping 169.254.0.2 > /dev/null &
$ sudo tcpdump -i eth0 | grep 169.254
...
18:59:07.113101 IP GCP_VM.(snip) > 169.254.0.2: ICMP echo request, i
d 32531, seq 0, length 64
18:59:08.137103 IP GCP_VM.(snip) > 169.254.0.2: ICMP echo request, i
d 32531, seq 1, length 64
...

Обновление (27 декабря)

Пинг от Router был успешным после установки его исходного адреса на 10.100.0.50, поскольку он пытался использовать 169.254.0.2 по умолчанию.

Пинг все еще не доходит OP_VM, и я все еще сталкиваюсь с проблемой конфигурации NAT, чтобы гарантировать правильность перевода.

Обновление (31 декабря)

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

После долгого тестирования и отладки я решил проблему соединения между GCP и локальной системой. Ниже приведены предпринятые шаги, а также соображения, сделанные при выявлении проблемы.

Анализируйте трафик с обоих направлений

Мне не хватало внимания, чтобы отделить трафик от оба направления. Это означает разбиение того, как каждый пакет будет перемещаться из / в источник / пункт назначения, и это даст четкое представление о том, где может лежать основная причина.

Пакет от GCP до локальной сети

  1. Пакет отправлен из GCP_VM (10.0.0.25) к HA_VPN (169.254.0.1/30)
  2. Пакет отправлен из GCP_VM (10.0.0.25) к Router (AS65002) (10.100.0.50)
  3. Пакет отправлен из GCP_VM (10.0.0.25) к DC Router Gateway (10.100.0.80)
  4. Пакет отправлен из GCP_VM (10.0.0.25) к OP_VM (10.100.0.200)
  5. Пакет отправлен из Router (AS65002) (10.100.0.50) к OP_VM (10.100.0.200)

Пакеты от локальной сети до GCP (обратный маршрут)

  1. Пакет отправлен из OP_VM (10.100.0.200) к Router (AS65002) (10.100.0.50)
  2. Пакет отправлен из OP_VM (10.100.0.200) к GCP_VM (10.0.0.25)
  3. Пакет отправлен из Router (AS65002) (10.100.0.50) к GCP_VM (10.0.0.25)

Учитывая указанные выше контрольные точки, статус был следующим:

  1. Это не тестировалось, поскольку конечная точка Cloud VPN (169.254.0.1/30) не входил в маршруты в VPC
  2. Я могу подтвердить ping удары Router (AS65002) (10.100.0.50), а также возвращается ответ (это означает, что соответствующий № 9 также подтвержден)
  3. Я мог бы НЕ подтвердить ping удары DC Router Gateway (10.100.0.80), так как ping не получил ответа
  4. Я мог бы НЕ подтвердить ping удары OP_VM (10.100.0.200), так как ping не получил ответа
  5. Я могу подтвердить ping удары OP_VM (10.100.0.200), а также возвращается ответ (это означает, что соответствующий № 7 также подтвержден)
  6. Как уже упоминалось, №6 также подтвердил этот трафик.
  7. Нет трафика соответствует этому случаю
  8. Как уже упоминалось, №2 также подтвердил этот трафик.

Ниже приведена диаграмма для описания ситуации.

    GCP_VM     HA_VPN (AS65001)     Router (AS65002)   (DC Router Gateway)    OP_VM
 10.0.0.25                          10.100.0.50        10.100.0.80            10.100.0.200

1. NA
2.    +--------------------------------> OK (response returned)
3.    +----------------------------------------------------x NG?
4.    +---------------------------------------------------------------------------x NG?
5.                                      +-----------------------------------------> OK (response returned)
6.                                   OK <-----------------------------------------+
7. No matching traffic
8. OK <--------------------------------+

Это поясняет, что любой трафик, исходящий из GCP_VM оставляет 2 возможных вопроса:

  • Возможность А. Пакет не доходит OP_VM (10.100.0.200)
  • Возможность B. Пакет достигает OP_VM (10.100.0.200), но ответ не возвращается Router (AS65002) (10.100.0.50)

Я мог подтвердить с помощью пунктов 5 и 6 выше, что пакет действительно достигает OP_VM (10.100.0.200) при запуске в Router (AS65002) (10.100.0.50). Это значит, Возможность А маловероятно. Сама роутинг работает как надо.

Это означало, что высока вероятность того, что ping ответ теряется, и никогда не попадает Router (AS65002) (10.100.0.50) назад. И для моего конкретного случая здесь это Возможность B была первопричиной проблемы.

Я мог подтвердить, что это так, создав имитацию сети, имитирующую ту же настройку, что и выше, и используя Wireshark для прослушивания в каждой точке. Это означает, что приведенная ниже диаграмма является реальным случаем.

    GCP_VM     HA_VPN (AS65001)     Router (AS65002)   (DC Router Gateway)    OP_VM
 10.0.0.25                          10.100.0.50        10.100.0.80            10.100.0.200

1. NA
2.    +--------------------------------> OK (response returned)
3.    +----------------------------------------------------> OK
4.    +---------------------------------------------------------------------------> OK
5.                                      +-----------------------------------------> OK (response returned)
6.                                   OK <-----------------------------------------+
7.               Where should I sent packet to??  LOST ---------------------------+
8. OK <--------------------------------+

Решение

В моем случае, когда трафик инициируется в GCP_VM, исходный IP-адрес был установлен на 10.0.0.25. Это означало, когда OP_VM пытается отправить трафик обратно, не может найти где 10.0.0.25, и пакет был потерян.

Мне пришлось добавить статическую запись NAT в Router (AS65002) сопоставить исходный IP-адрес 10.0.0.25 к 10.100.0.50 когда пакет уходит Router (AS65002), таким образом OP_VM может правильно направить трафик обратно в Router (AS65002). После получения ответа NAT снова вступает в силу и Router (AS65002) затем заменяет 10.100.0.50 с участием 10.0.0.25, и отправляет пакеты обратно в GCP_VM.

Это похоже на проблему с маршрутизацией на месте. Думаю, OP_VM нет пути к 10.0.0.0/24 и как результат отправить его на шлюз по умолчанию DC Router Gateway и там он упал, потому что DC Router Gateway (10.100.0.80) также нет маршрута к 10.0.0.0/24 (потому что вы смотрите на Router).

Чтобы решить эту проблему, вы должны установить статический маршрут в OP_VM к 10.0.0.0/24 через Router и хранить DC Router Gateway как шлюз по умолчанию.

Вы должны удалить маршрут ip route 10.100.0.0/24 gateway 10.100.0.50 из Router- сеть 10.100.0.0/24 напрямую связана с ним.

РЕДАКТИРОВАТЬ

С GCP_VM я могу успешно пропинговать 10.100.0.50 (маршрутизатор).

На данный момент похоже, что вы правильно настроили пиринг между Router и HA_VPN.

Вы должны иметь возможность пинговать GCP_VM и OP_VM из Router а также Router из OP_VM быть на правильном пути.

При настройке маршрутизатора что-то вроде

 ip route 10.100.0.0/24 gateway 10.100.0.80

При настройке маршрутизатора что-то вроде

 ip route 10.100.0.0/24 gateway 10.100.0.80

Эти маршруты не нужны, потому что Router напрямую подключен к подсети 10.100.0.0/24 и имеет IP 10.100.0.50

Однако из GCP_VM пинг до 10.100.0.200 (OP_VM) пропадает.

Это ожидается, потому что OP_VM и DC Router Gateway нет пути к 10.0.0.0/24 как я уже упоминал выше и не могу ответить, и вам нужно установить статический маршрут на OP_VM к 10.0.0.0/24 через Router и хранить DC Router Gateway как шлюз по умолчанию.

РЕДАКТИРОВАТЬ 2 OP_VM отправил ответы на DC Router Gateway потому что у него нет маршрута к 10.100.0.0/24, и он пытается достичь его через шлюз по умолчанию, а DC Router Gateway они упали, потому что также нет маршрута.

Вы должны добавить статический маршрут в OP_VM или в DC Router Gateway к 10.100.0.0/24 решить это.