înregistrare Logare
Puncte:1
avatar Server

De ce este direcționat traficul între diferite dispozitive veth?

drapel ua
kriomant

Am o problemă: există o cale de rută neașteptată între dispozitivele de rețea virtuală.

Să creăm două perechi independente de dispozitive veth-peer:

$ sudo ip link add veth0 tip veth peer name peer0
$ sudo ip link add veth1 tip veth peer name peer1

Atribuiți adrese dispozitivelor peerX:

$ sudo ip addr add ab:: dev peer0
$ sudo ip addr add cd:: dev peer1

Configurați toate dispozitivele:

$ sudo ip link set dev veth0 up
$ sudo ip link set dev veth1 up
$ sudo ip link set dev peer1 up
$ sudo ip link set dev peer0 up

Verificați dispozitivele:

$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue stare UNKNOWN grup implicit qlen 1000
    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 pentru totdeauna preferred_lft pentru totdeauna
    inet6 ::1/128 scope host
       valid_lft pentru totdeauna preferred_lft pentru totdeauna
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 02:82:b2:df:b0:58 brd ff:ff:ff:ff:ff:ff
    inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic enp0s3
       valid_lft 84429sec preferred_lft 84429sec
    inet6 fe80::82:b2ff:fedf:b058/64 scope link
       valid_lft pentru totdeauna preferred_lft pentru totdeauna
3: peer0@veth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue stare UP grup implicit qlen 1000
    link/ether 6e:8d:c0:7c:02:9c brd ff:ff:ff:ff:ff:ff
    inet6 ab::/128 scope global
       valid_lft pentru totdeauna preferred_lft pentru totdeauna
    inet6 fe80::6c8d:c0ff:fe7c:29c/64 scope link
       valid_lft pentru totdeauna preferred_lft pentru totdeauna
4: veth0@peer0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue stare UP grup implicit qlen 1000
    link/ether 4e:43:26:75:10:11 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::4c43:26ff:fe75:1011/64 scope link
       valid_lft pentru totdeauna preferred_lft pentru totdeauna
5: peer1@veth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue stare UP grup implicit qlen 1000
    link/ether ea:8c:82:e6:2e:a9 brd ff:ff:ff:ff:ff:ff
    inet6 cd::/128 scope global
       valid_lft pentru totdeauna preferred_lft pentru totdeauna
    inet6 fe80::e88c:82ff:fee6:2ea9/64 scope link
       valid_lft pentru totdeauna preferred_lft pentru totdeauna
6: veth1@peer1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue stare UP grup implicit qlen 1000
    link/ether da:5a:68:b1:e8:43 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::d85a:68ff:feb1:e843/64 scope link
       valid_lft pentru totdeauna preferred_lft pentru totdeauna

si trasee:

$ ip r
implicit prin 10.0.2.2 dev enp0s3 proto dhcp src 10.0.2.15 metric 100
10.0.2.0/24 dev enp0s3 proto kernel scope link src 10.0.2.15
10.0.2.2 dev enp0s3 proto dhcp scope link src 10.0.2.15 metric 100

Acum ascultați peer0 pe portul UDP 2000:

$ nc -u -6 -l ab:: 2000

Și trimiteți pachetul peer1:

$ echo -n abc nc -u -6 -s cd:: ab:: 2000

Și ascultând nc imprimeuri abc! Dar De ce? peer0 și peer1 nu sunt conectate în niciun fel. Dacă am înțeles bine, ascult nc ar trebui să se lege de peer0 si trimiterea nc ar trebui să se lege de peer1.

28
0 + 0
Puncte:1
A.B avatar Server
drapel cl
A.B

peer0 și peer1 nu sunt conectate în niciun fel.

Toate sunt interfețe aparținând sistemului, deci sunt conectate la sistem. Rutarea are loc pe sistem.Sistemul va comunica între adresele care îi aparțin în mod direct, fără a trimite pachete în exterior, adică fără a trimite pachete prin interfețele veth, ci folosind interfața sa de loopback (dev lo de mai jos):

# ip route get from cd:: to ab::
local ab:: din cd:: dev lo table local proto kernel src ab:: metric 0 pref medium

De asemenea, nu că ar ajuta prea mult aici, dar când se afișează rute fără nicio valoare IPv6 pentru a sugera IPv6, -6 trebuie dat, sau este implicit la IPv4.

# ip -6 ruta
ab:: dev peer0 proto kernel metric 256 pref mediu
cd:: dev peer1 proto kernel metric 256 pref mediu
fe80::/64 dev peer1 proto kernel metric 256 pref mediu
fe80::/64 dev veth1 proto kernel metric 256 pref mediu
fe80::/64 dev peer0 proto kernel metric 256 pref mediu
fe80::/64 dev veth0 proto kernel metric 256 pref mediu
# ip -6 ruta arată tabelul local
local ::1 dev lo proto kernel metric 0 pref mediu
local fe80::4c43:26ff:fe75:1011 dev veth0 proto kernel metric 0 pref mediu
local fe80::6c8d:c0ff:fe7c:29c dev peer0 proto kernel metric 0 pref mediu
local fe80::d85a:68ff:feb1:e843 dev veth1 proto kernel metric 0 pref mediu
local fe80::e88c:82ff:fee6:2ea9 dev peer1 proto kernel metric 0 pref mediu
multicast ff00::/8 dev veth1 proto kernel metric 256 pref mediu
multicast ff00::/8 dev peer1 proto kernel metric 256 pref mediu
multicast ff00::/8 dev veth0 proto kernel metric 256 pref mediu
multicast ff00::/8 dev peer0 proto kernel metric 256 pref mediu
0 + 0
drapel ua
kriomant
Multumesc. Deci, pentru a le izola, trebuie să folosesc spații de nume de rețea separate?
0
Răspunde
A.B avatar
drapel cl
A.B
Nu știu exact ce intenționați să faceți și de ce există două perechi de interfețe Veth în loc de o singură pereche, dar da, principala utilizare a interfețelor Veth este în spațiile de nume ale rețelei (există alte utilizări mai puțin obișnuite în același spațiu de nume atunci când folosind și o punte).
0
Răspunde
drapel romania
SEF 777
întrebarea această in alte limbi:

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.