Localhost için GRE Tüneli

0

Yerel bir Linux ağ ad alanı hafif VM'yi yerel HOST makinesine bağlamak için bir GRE Tüneli (veya TAP) kullanmaya çalışıyorum. Ana bilgisayardan gelen yanıtların VM'ye geri dönmemesi dışında her şey çalışıyor gibi görünüyor .

Kurulumum:

HOST gerçek IP'si: 10.1.101.101/24

HOST GRE (Kur benzeri):

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 Ağ yapılandırması:

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 yolları:

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

EV SAHİBİ iptables (IE: boştur iptables -F)

VM Ağı yapılandırması:

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

VM rotaları:

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

Şimdi HOST ping 10.201.0.2VM gelen 10.201.0.1ve yakalama paketleri:

tcpdump -ni gre1 HOST'ta:

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'de:

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

Öyleyse, AFAICS VM ARP İsteğini HOST'a gönderiyor, HOST ARP'ye (Doğru) cevap veriyor, ancak ARP paketi GRE tüneli boyunca geri gelmiyor mu?

Not 1: VM, CORE Emulator adlı bir ürün tarafından oluşturulur ve bir GRE Node'a bağlı temel bir yönlendiriciden oluşur , bu düğüm işaret eder ve anahtar 101'dir.10.1.101.101

Not 2: Yerelde Core Emulator kullanmak yerine, farklı bir makinede çalıştırıyorsam, ancak aynı ayarlarla aynı yapılandırma düzgün çalışıyorsa (10.1.101.101 kullanarak).

HOST GRE Tunnel'ı şu şekilde ayarlamayı da denedim:

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

VM GRE düğüm işaret127.0.0.1

ama aynı sonucu almak ARP görmüş ve HOST tarafından yanıtlanan ama değil VM tarafından görülen.

DÜZENLEME 1:
"Gerçek dünya" sorunuma cevap olarak, CORE bana burada açıklandığı gibi uygun bir çözüm sağlıyor: https://downloads.pf.itd.nrl.navy.mil/docs/core/core-core-html/usage # diğer-yöntemlerini .html

EDIT 2: Sonraki soru?
HOST makinesiyle GRE tüneli üzerinden bir "Linux Konteyner / Ağ isim alanı / LXC" vb. VM kurulabiliyor mu? GRE tünel bitiş noktaları gibi bir şey olurdu HOST:127.0.0.1için VM:?.?.?.?(O soru işaretleri sonucuna varmama neden VM neden ARP olabilir VM dönüş yolunu yok HOST 127.0.0.1 için göndermek mümkün bir dönemde, ilk soruma göre, VM'ye ulaşamıyor).

Bunu okumak için zaman ayırdığınız için teşekkür ederiz, herhangi bir yardım büyük beğeni topluyor.

linux  networking  virtual-machine  tunnel 
— dotvotdot
kaynak

Yanıtlar:

1

Kısmi cevap: GRE tüneli normal bir bağlantının üzerinde çalışır ve size ağ paketlerinde tünel başlıklarını ekleyen / silen ek bir ağ arayüzü sunar.

Yani iki makine A ve B arasında bir tünel yapmak için normal kurulum şudur:

1) A ve B'nin "normal" IP adresleri olduğunu ve birbirlerini görebildiklerini kontrol edin. Bir onun IP "10.0.0.1/24" varsa Örneğin, eth0ve B onun üzerinde "10.0.0.2/24" IP IP vardır eth0, bir do ping 10.0.0.2A ve ping 10.0.0.1B'de

2) A’nın A yerel IP’si ve B’nin uzak IP’si olan bir tünel aygıtı ekleyin, arayüze yeni bir IP ekleyin:

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) Uygun IP adresleriyle B için aynı:

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) Tünelin çalışıp çalışmadığını görmek ping 10.0.44.2için A ve ping 10.0.44.1B üzerinde yapın.

Gördüğünüz gibi, yaptığınız kurulum bu değil: HOST üzerindeki tünelin yerel ve uzak adresiniz aynı, VM'deki tünelin yerel ve uzak adresi yok, VM'deki tünel arayüzleri kapalı ve Tünele ait IP adresi sona erdi eth0. Bunların hiçbiri gerçekten mantıklı değil, bu yüzden işe yaramazsa sürpriz değil.

Core Emulator'un "GRE Nodes" u nasıl yönettiğini bilmiyorum, ama gösterdiğiniz yapılandırmadan, bu sadece GRE arayüzünü yapılandırmak için bir katman gibi görünüyor. Öyleyse Core Emulator'ın bunları nasıl işlediğini öğrenin veya emülatördeki "GRE Node" ları unutun ve elle yapılandırın.

Daha da iyisi, bir egzersiz olarak, Core Emulator'a bağlı iki VM A ve B'yi yapılandırın ve daha sonra yukarıda belirtilen şekilde GRE tünellerini manuel olarak ekleyin. Bu simetrik bir durumdur ve en az kafa karıştırıcı olmalıdır.

— dirkt
kaynak
Merhaba, ilk önce "Egzersizinizi" denedim ve iki VM (A & B) arasında basit bir GRE tüneli kuruyor ve iki ucu da ping yapabiliyor. "CORE" sorununa daha derin bakmam gerekiyor. Ayrıca asıl soruya daha fazla ayrıntı ekleyeceğim.
— dotvotdot
Bilginize: ip add dev gre0 fooolmalı ip addr add dev gre0 foo.. benim yazı düzenlememi reddedildi.
— dotvotdot
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.