Я пытаюсь использовать GRE Tunnel (или TAP) для подключения облегченной виртуальной машины пространства имен локальной сети Linux к локальной машине HOST. Кажется, все работает, за исключением того, что ответы от хоста не возвращаются на виртуальную машину.

Моя настройка:

ХОСТ реальный IP: 10.1.101.101/24

HOST GRE (настройка вроде так):

ip l add dev gre1 type gretap remote 10.1.101.101 local 10.1.101.101 key 101
ip a add dev gre1 10.201.0.2/24
ip l set dev gre1 up

HOST Network config:

ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:30:1b:42:65:ac brd ff:ff:ff:ff:ff:ff
    inet 10.1.101.101/24 brd 10.1.101.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::230:1bff:fe42:65ac/64 scope link 
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 00:50:04:d0:50:0f brd ff:ff:ff:ff:ff:ff

82: gre0@NONE: <NOARP> mtu 1476 qdisc noop state DOWN group default 
    link/gre 0.0.0.0 brd 0.0.0.0
83: gretap0@NONE: <BROADCAST,MULTICAST> mtu 1462 qdisc noop state DOWN group default qlen 1000
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
84: gre1@NONE: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 65494 qdisc pfifo_fast state UNKNOWN group default qlen 1000
    link/ether e2:83:0d:a4:cc:23 brd ff:ff:ff:ff:ff:ff
    inet 10.201.0.2/24 scope global gre1
       valid_lft forever preferred_lft forever
    inet6 fe80::e083:dff:fea4:cc23/64 scope link tentative dadfailed 
       valid_lft forever preferred_lft forever

HOST маршруты:

ip r
default via 10.1.101.1 dev eth0 
10.1.101.0/24 dev eth0  proto kernel  scope link  src 10.1.101.101 
10.201.0.0/24 dev gre1  proto kernel  scope link  src 10.201.0.2 
169.254.0.0/16 dev eth0  scope link  metric 1000

HOST iptables пуст (IE: iptables -F)

Конфигурация сети VM:

ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: gre0@NONE: <NOARP> mtu 1476 qdisc noop state DOWN group default 
    link/gre 0.0.0.0 brd 0.0.0.0
3: gretap0@NONE: <BROADCAST,MULTICAST> mtu 1462 qdisc noop state DOWN group default qlen 1000
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
114: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:00:00:aa:00:00 brd ff:ff:ff:ff:ff:ff
    inet 10.201.0.1/24 brd 10.201.0.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::200:ff:feaa:0/64 scope link 
       valid_lft forever preferred_lft forever

Маршруты ВМ:

ip r
10.201.0.0/24 dev eth0  proto kernel  scope link  src 10.201.0.1

Теперь пропингуйте HOST 10.201.0.2 с VM 10.201.0.1 и перехватите пакеты:

tcpdump -ni gre1 на хосте :

11:57:36.379404 ARP, Request who-has 10.201.0.2 tell 10.201.0.1, length 28
11:57:36.379431 ARP, Reply 10.201.0.2 is-at e2:83:0d:a4:cc:23, length 28
11:57:36.379455 ARP, Reply 10.201.0.2 is-at e2:83:0d:a4:cc:23, length 28
11:57:37.376634 ARP, Request who-has 10.201.0.2 tell 10.201.0.1, length 28
11:57:37.376658 ARP, Reply 10.201.0.2 is-at e2:83:0d:a4:cc:23, length 28
11:57:37.376683 ARP, Reply 10.201.0.2 is-at e2:83:0d:a4:cc:23, length 28
11:57:38.376539 ARP, Request who-has 10.201.0.2 tell 10.201.0.1, length 28
11:57:38.376567 ARP, Reply 10.201.0.2 is-at e2:83:0d:a4:cc:23, length 28
11:57:38.376596 ARP, Reply 10.201.0.2 is-at e2:83:0d:a4:cc:23, length 28

tcpdump -ni eth0 на виртуальной машине:

11:57:36.379243 ARP, Request who-has 10.201.0.2 tell 10.201.0.1, length 28
11:57:37.376384 ARP, Request who-has 10.201.0.2 tell 10.201.0.1, length 28
11:57:38.376384 ARP, Request who-has 10.201.0.2 tell 10.201.0.1, length 28

Итак, AFAICS VM отправляет запрос ARP в HOST, HOST отвечает на ARP (правильно), но пакет ARP не возвращается через туннель GRE?

Примечание 1: ВМ создается продуктом под названием Эмулятор CORE и состоит из базового маршрутизатора, подключенного к узлу GRE, этот узел указывает на 10.1.101.101 а ключ - на 101

Примечание 2: Если вместо локального эмулятора ядра я запускаю его на другом компьютере, но с теми же настройками, то та же конфигурация работает должным образом (с использованием 10.1.101.101).

Я также попытался настроить HOST GRE Tunnel на:

ip l add gre1 type gretap remote 127.0.0.1 local 127.0.0.1 key 101

и узел VM GRE, чтобы указать на 127.0.0.1

но я получаю тот же результат, ARP виден и на него отвечает HOST, но не видит виртуальная машина.

РЕДАКТИРОВАТЬ 1:
В ответ на мою проблему "реального мира", CORE предоставляет мне подходящее решение, как описано здесь: https://downloads.pf.itd.nrl.navy.mil/docs/core/core-html/usage.html# другие-методы

РЕДАКТИРОВАТЬ 2: следующий вопрос?
Может ли виртуальная машина «Контейнер Linux / Сетевое пространство имен / LXC» и т.д. Обмениваться данными с компьютером HOST через туннель GRE. Конечные точки туннеля GRE будут выглядеть примерно так HOST:127.0.0.1 для VM:?.?.?.? (Эти знаки вопроса приводят меня к выводу, что, хотя виртуальная машина может отправлять 127.0.0.1, HOST не имеет пути возврата к виртуальной машине, возможно, именно поэтому ARP в моем первоначальном вопросе не проходит в ВМ).

Спасибо, что нашли время, чтобы прочитать это, любая помощь очень ценится.

|источник

1 ответ1

1

Частичный ответ: туннель GRE работает поверх обычного соединения и предоставляет вам дополнительный сетевой интерфейс, который добавляет / удаляет заголовки туннеля в сетевых пакетах.

Таким образом, обычная настройка для создания туннеля между двумя компьютерами A и B выглядит следующим образом:

1) Убедитесь, что A и B имеют "нормальные" IP-адреса и могут видеть друг друга. Например, если A имеет IP «10.0.0.1/24» на своем eth0 а B имеет IP IP «10.0.0.2/24» на своем eth0 , выполните ping 10.0.0.2 на A и ping 10.0.0.1 на B.

2) Добавьте туннельное устройство на A с локальным IP-адресом A и удаленным IP-адресом B, добавьте новый IP-адрес в интерфейс:

ip link add dev gre0 type gretap remote 10.0.0.2 local 10.0.0.1 key 123
ip addr add 10.0.44.1/24 dev gre0 
ip link set gre0 up

3) То же самое для B, с соответствующими IP-адресами:

ip link add dev gre0 type gretap remote 10.0.0.1 local 10.0.0.2 key 123
ip addr add 10.0.44.2/24 dev gre0
ip link set gre0 up

4) Выполните ping 10.0.44.2 на A и ping 10.0.44.1 на B, чтобы увидеть, работает ли туннель.

Как видите, это не та настройка, которая у вас есть: ваш локальный и удаленный адрес для туннеля на HOST одинаков, нет локального и удаленного адреса для туннеля на виртуальной машине, интерфейсы туннеля на виртуальной машине не работают, и IP-адрес, принадлежащий туннелю, оказался на eth0 . Ничто из этого не имеет смысла, поэтому неудивительно, что это не работает.

Я не знаю, как Core Emulator обрабатывает «GRE-узлы», но из конфигурации, которую вы показали, это просто уровень для настройки интерфейса GRE. Так что либо выясните, как Core Emulator справляется с ними, либо забудьте о "GRE Nodes" в эмуляторе, и настройте его вручную.

Более того, в качестве упражнения настройте две виртуальные машины A и B, которые подключены в эмуляторе ядра, а затем вручную добавьте туннели GRE, как описано выше. Это симметричная ситуация, и она должна быть наименее запутанной.

|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .