GRE Тунель до localhost

Я намагаюся використовувати тунель GRE (або TAP) для підключення локальної мережі ІМ з невеликою вагою локальної мережі Linux до локальної машини HOST. Це, здається, працює, за винятком того, що відповіді від хоста не повертають його до VM.

Моя установка:

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:

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 на VM:

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 Emulator і складається з базового маршрутизатора, приєднаного до GRE-вузла , на цей вузол вказується 10.1.101.101і ключ 101

Примітка 2: Якщо замість локального використання емулятора Core я запускаю його на іншій машині, але з усіма тими ж налаштуваннями, однакова конфігурація працює належним чином (використовуючи 10.1.101.101).

Я також спробував встановити тунель HOST GRE на:

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, але не бачить VM.

EDIT 1:
Відповідаючи на мою проблему "реального світу", CORE пропонує мені відповідне рішення, як описано тут: https://downloads.pf.itd.nrl.navy.mil/docs/core/core-html/usage .html # інші методи

EDIT 2: Подальше запитання?
Чи можливо для "Linux контейнера / мережевого простору імен / LXC" тощо VM спілкуватися з машиною HOST через тунель GRE. В кінцевих точках тунелю GRE будуть що - щось на зразок HOST:127.0.0.1до VM:?.?.?.?(Ці знаки питання привели мене до висновку , що в той час як віртуальна машина може бути в змозі відправити 127.0.0.1 хост не має зворотний шлях до віртуальної машини, яка могла б бути , чому ARP, у моєму первинному питанні не потрапляє до ВМ).

Дякуємо, що знайшли час, щоб прочитати це, будь-яка допомога дуже вдячна.

Часткова відповідь: тунель 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 і 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на А і ping 10.0.44.1на В, щоб побачити, чи працює тунель.

Як бачите, це не налаштування, яке ви маєте: Ваша локальна та віддалена адреса для тунелю на HOST однакова, немає локальної та віддаленої адреси для тунелю на VM, інтерфейси тунелю на VM - вниз, і IP-адреса, що належить до тунелю, закінчилася eth0. Нічого з цього насправді не має сенсу, тому не дивно, що це не працює.

Я не знаю, як основний емулятор обробляє "GRE Nodes", але з конфігурації, яку ви показали, це здається просто шаром для налаштування інтерфейсу GRE. Тож або з’ясуйте, як Core Emulator обробляє їх, або забудьте про "GRE Nodes" в емуляторі та налаштуйте його вручну.

Ще краще, як вправу, налаштуйте два VM A і B, які з'єднані в емуляторі Core, а потім додайте тунелі GRE вручну, як описано вище. Це симетрична ситуація, і вона повинна бути найменш заплутаною.