înregistrare Logare
Puncte:0
jwbensley avatar Server

Nu se pot înlănțui mai mult de un spațiu de nume de rețea împreună

drapel de
jwbensley

Declarație problemă

Cu configurația de mai jos este creată o pereche veth între spațiul de nume implicit/principal și un netns numit ns1.

Configurația creează și o a doua pereche veth: veth2 este în netns ns1 iar veth3 este in netns ns2, aceasta se alătură ns1 la ns2 crearea lanțului: implicit netns-veth0 <-> veth1-ns1-veth2 <-> veth3-ns2.

sudo ip link add veth0 tip veth peer name veth1
sudo ip -6 addr add CCFF::0/127 peer CCFF::1/127 dev veth0
sudo ip link set up dev veth0

sudo ip netns add ns1
sudo ip link set veth1 netns ns1
sudo ip -n ns1 -6 addr add CCFF::1/127 peer CCFF::0/127 dev veth1
sudo ip -n ns1 link set up dev veth1
sudo ip -n ns1 -6 route add default prin CCFF::0

sudo ip link add veth2 tip veth peer name veth3
sudo ip link set veth2 netns ns1
sudo ip -n ns1 -6 addr add CCFF::2/127 peer CCFF::3/127 dev veth2
sudo ip -n ns1 link set up dev veth2
sudo ip -n ns1 -6 route add CCFF::/64 prin CCFF::3

sudo ip netns adauga ns2
sudo ip link set veth3 netns ns2
sudo ip -n ns2 -6 addr add CCFF::3/127 peer CCFF::2/127 dev veth3
sudo ip -n ns2 link set up dev veth3
sudo ip -n ns2 -6 route add default prin CCFF::2

sudo ip -6 r adăugați CCFF::/64 prin CCFF::1

Din rețelele implicite pot ping veth0 care este în același netns. Din rețelele implicite pot trimite ping la veth1 și veth2, care sunt ambele în ns1. Din netn-urile implicite nu pot să pintez veth3 care este în ns2.

Dacă extind modificarea după cum urmează, adăugând veth4 în ns2 si veth5 in ns3 Am aceeasi problema. Pot da ping din orice interfață ns1 la orice interfață în ns2, dar nu pot ajunge la nicio interfață în ns3.

sudo ip link add veth4 tip veth peer name veth5
sudo ip link set veth4 netns ns2
sudo ip netns exec ns2 ip -6 addr add CCFF::4/127 peer CCFF::5/127 dev veth4
sudo ip netns exec ns2 ip link set up dev veth4
sudo ip netns exec ns2 ip -6 route add CCFF::/64 prin CCFF::5

sudo ip netns adauga ns3
sudo ip link set veth5 netns ns3
sudo ip netns exec ns3 ip -6 addr add CCFF::5/127 peer CCFF::4/127 dev veth5
sudo ip netns exec ns3 ip link set up dev veth5
sudo ip netns exec ns3 ip -6 route add default prin CCFF::4

Se pare că pot face ping doar la o interfață dintr-o rețea „învecinată”/„conectată” direct la cea din care fac ping. Nu pot face ping printr-un lanț de spații de nume net. Rutarea este valabilă; netn-urile implicite pot trimite ping la orice interfață ns1 dar nimic mai mult, interfețe în ns1 poate ping orice interfață în netns sau implicit ns2 dar nimic in ns3, și ns3 poate ping orice ns2 dar nimic dincolo de in ns1 sau netn-urile implicite.

Este aceasta o limitare a spațiilor de nume de rețea?

Depanare

Redirecționarea IPv6 este activată, ip6tables este doar setat la „permite tot”, nu sunt sigur ce altceva să verific.

$ip -6 r
ccff::1 dev veth0 proto kernel metric 256 pref mediu
ccff::/127 dev veth0 proto kernel metric 256 pref mediu
ccff::/64 prin ccff::1 dev veth0 metric 1024 pref mediu
fe80::/64 dev veth0 proto kernel metric 256 pref mediu

$sudo ip -n ns1 -6 r
ccff:: dev veth1 proto kernel metric 256 pref mediu
ccff::/127 dev veth1 proto kernel metric 256 pref mediu
ccff::3 dev veth2 proto kernel metric 256 pref mediu
ccff::2/127 dev veth2 proto kernel metric 256 pref mediu
ccff::/64 prin ccff::3 dev veth2 metric 1024 pref mediu
fe80::/64 dev veth1 proto kernel metric 256 pref mediu
fe80::/64 dev veth2 proto kernel metric 256 pref mediu
implicit prin ccff:: dev veth1 metric 1024 pref mediu

$sudo ip -n ns2 -6 r
ccff::2 dev veth3 proto kernel metric 256 pref mediu
ccff::2/127 dev veth3 proto kernel metric 256 pref mediu
ccff::5 dev veth4 proto kernel metric 256 pref mediu
ccff::4/127 dev veth4 proto kernel metric 256 pref mediu
ccff::/64 prin ccff::5 dev veth4 metric 1024 pref mediu
fe80::/64 dev veth3 proto kernel metric 256 pref mediu
fe80::/64 dev veth4 proto kernel metric 256 pref mediu
implicit prin ccff::2 dev veth3 metric 1024 pref mediu

$sudo ip -n ns3 -6 r
ccff::4/127 dev veth5 proto kernel metric 256 linkdown pref mediu
implicit prin ccff::4 dev veth5 metric 1024 linkdown pref medium

$cat /proc/sys/net/ipv6/conf/all/forwarding 
1

$cat /proc/sys/net/ipv6/conf/default/forwarding 
1

$sudo ip6tables-save
# Generat de ip6tables-save v1.8.4 pe miercuri 17 noiembrie 22:02:48 2021
*filtru
:INPUT ACCEPT [76565:173401906]
: FORWARD ACCEPT [0:0]
: ACCEPT IEȘIRE [50440:6536664]
COMMIT
# Finalizat miercuri 17 noiembrie 22:02:48 2021

$lsb_release -a
Nu sunt disponibile module LSB.
ID distribuitor: Ubuntu
Descriere: Ubuntu 20.04.3 LTS
Lansare: 20.04
Nume de cod: focal

$uname -a
Linux l13-ubuntu 5.11.0-40-generic #44~20.04.2-Ubuntu SMP Mar 26 octombrie 18:07:44 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
164
0 + 0
Puncte:2
dirkt avatar Server
drapel in
dirkt

Redirecționarea IPv6 este activată

Probabil că nu: când am încercat acest lucru pe sistemul meu cu comenzile date la începutul întrebării, nici nu pot ajunge veth3:

$ ping -6 CCFF::3
PING CCFF::3(ccff::3) 56 de octeți de date
^C
--- CCFF::3 statistici ping ---
13 pachete transmise, 0 primite, 100% pierdere de pachete, timp 12290 ms

Cu toate acestea, când activez redirecționarea în ns1

ecou 1 | sudo ip netns exec ns1 tee /proc/sys/net/ipv6/conf/all/forwarding

funcționează:

$ ping -6 CCFF::3
PING CCFF::3(ccff::3) 56 de octeți de date
64 de octeți din ccff::3: icmp_seq=1 ttl=63 time=0,112 ms
64 de octeți din ccff::3: icmp_seq=2 ttl=63 time=0,054 ms

Deci, este posibil să nu aveți și redirecționarea IPv6 activată ns1. (Și amintiți-vă că redirecționarea este per spațiu de nume; l-ați activat în spațiul de nume principal, dar nu în ns1?)

Am depanat acest lucru făcând a tcpdump pe fiecare interfață; că ping-urile nu au ajuns veth2 a fost un semn că redirecționarea nu a fost activată.

Și dacă vă întrebați „dar de ce pot face ping veth2 dacă redirecționarea nu este activată”: Linux tratează toate adresele locale la fel, astfel încât să puteți ajunge la orice adresă locală din orice interfață. Acest lucru nu are nicio legătură cu redirecționarea.

BTW, vă ajută pe mulți dintre voi să conduceți un xterm în fiecare spațiu de nume; care face depanarea mult mai ușoară.

0 + 0
jwbensley avatar
drapel de
jwbensley
M-am gândit că setarea „/proc/sys/net/ipv6/conf/default/forwarding” în ns implicit va fi moștenită în orice ns nou creat. Ce prost am fost. Mulțumesc @dirkt.
1
Răspunde
Puncte:1
Gerrit avatar Server
drapel cn
Gerrit

Am ajuns la aceeași concluzie total validă ca și @dirkt, fiecare spațiu de nume este o gazdă de rețea în sine, inclusiv setarea dacă se comportă sau nu ca un router (care este dezactivat implicit). Setările /proc/sys/net sunt separate pentru fiecare spațiu de nume. rezolvarea este separată, legăturile de interfață sunt separate (dar numele de gazdă nu este, pentru asta trebuie să creați spații de nume UTS). Deci, practic, acesta este răspunsul tău.

Pentru a nu scădea oricum, dar pentru referințe viitoare, voi adăuga câteva lucruri și voi rearanja și simplifica ușor acest lucru. De fapt, nu aveți nevoie de setarea de rutare în spațiul de nume implicit, cu excepția cazului în care doriți să direcționați traficul exterior către aceste spații de nume sau invers.

Pentru a rezuma o construcție pentru spațiul de nume implicit și ns1 plus ns2.

# creați spații de nume
ip netns adauga ns1
ip netns adauga ns2

# bucle inverse, plăcut să aveți
ip -n ns1 link set lo up
ip -n ns2 link set lo up

# faceți vete perechi pentru fiecare spațiu de nume nou
ip link add veth0 tip veth peer name veth1
ip link add veth2 tip veth peer name veth3

# adăugați interfețe la spațiile lor de nume
set de legături ip veth1 netns ns1
set de legături ip veth2 netns ns1
set de legături ip veth3 netns ns2

# atribuiți adrese
ip -6 addr add CCFF::0/127 dev veth0
ip -n ns1 -6 addr add CCFF::1/127 dev veth1
ip -n ns1 -6 addr add CCFF::2/127 dev veth2
ip -n ns2 -6 addr add CCFF::3/127 dev veth3

# setați noile legături la sus
Configurați legătura IP dev veth0
ip -n ns1 link set up dev veth1
ip -n ns1 link set up dev veth2
ip -n ns2 link set up dev veth3

# de spații de nume care ar trebui să redirecționeze
ip netns exec ns1 sysctl -w net.ipv6.conf.all.forwarding=1

# direcționați orice ip6 către gazdă prin spațiul de nume 1
ip -n ns2 -6 route add default prin CCFF::2

# rutați orice ccff ip6 spre interior de la gazdă
# la un spațiu mai interior prin spațiul de nume 1
ip -6 r adăugați CCFF::/64 prin CCFF::1

Câteva teste pe care le puteți face apoi:

lista IP netns
ip netns exec ns2 ping6 ccff::0
ip netns exec ns2 ping6 ccff::1
ip netns exec ns2 ping6 ccff::3

# Sau puneți shell-ul (de exemplu, bash) în spațiul de nume ns2
ip netns exec ns2 /bin/bash
ping6 ccff::0
Ieșire

Puteți, de asemenea, să rezolvați și să găzduiți modificări ale fișierelor

# Configurați un resolver 
# (înlocuiește cu propriul tău DNS, nu funcționează cu un rezolutor loopback)

mkdir -p /etc/netns/ns2
echo nameserver dns-ip > /etc/netns/ns2/resolv.conf

# Poate da-i propriul fișier hosts, pentru a face editări
cp /etc/hosts /etc/netns/ns2/hosts
0 + 0
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.