Score:1

เหตุใดจึงมีการกำหนดเส้นทางการรับส่งข้อมูลระหว่างอุปกรณ์ veth ต่างๆ

ธง ua

ฉันมีปัญหา: มีเส้นทางที่ไม่คาดคิดระหว่างอุปกรณ์เครือข่ายเสมือน

มาสร้างคู่อุปกรณ์ veth-peer อิสระสองคู่:

$ sudo ip link เพิ่ม veth0 พิมพ์ veth ชื่อเพียร์ peer0
$ sudo ip link เพิ่ม veth1 พิมพ์ veth peer name peer1

กำหนดที่อยู่ให้กับอุปกรณ์ peerX:

$ sudo ip addr เพิ่ม ab:: dev peer0
$ sudo ip addr เพิ่ม cd:: dev peer1

ตั้งค่าอุปกรณ์ทั้งหมด:

$ sudo ip link ตั้งค่า dev veth0 ขึ้น
$ sudo ip link ตั้งค่า dev veth1 ขึ้น
$ sudo ip link ตั้งค่า dev peer1 ขึ้น
$ sudo ip link ตั้งค่า dev peer0 ขึ้น

ตรวจสอบอุปกรณ์:

$ ไอพี
1: จริง: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN กลุ่มเริ่มต้น qlen 1,000
    ลิงค์ / ย้อนกลับ 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 ขอบเขตโฮสต์เลย
       valid_lft ตลอดไป reserved_lft ตลอดไป
    inet6 ::1/128 ขอบเขตโฮสต์
       valid_lft ตลอดไป reserved_lft ตลอดไป
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP กลุ่มเริ่มต้น qlen 1000
    ลิงค์/อีเธอร์ 02:82:b2:df:b0:58 brd ff:ff:ff:ff:ff:ff
    inet 10.0.2.15/24 brd 10.0.2.255 ขอบเขตโกลบอลไดนามิก enp0s3
       valid_lft 84429วินาทีที่ต้องการ_lft 84429วินาที
    ลิงค์ขอบเขต inet6 fe80::82:b2ff:fedf:b058/64
       valid_lft ตลอดไป reserved_lft ตลอดไป
3: peer0@veth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP กลุ่มเริ่มต้น qlen 1000
    ลิงค์/อีเธอร์ 6e:8d:c0:7c:02:9c brd ff:ff:ff:ff:ff:ff
    inet6 ab::/128 ขอบเขตทั่วโลก
       valid_lft ตลอดไป reserved_lft ตลอดไป
    ลิงค์ขอบเขต inet6 fe80::6c8d:c0ff:fe7c:29c/64
       valid_lft ตลอดไป reserved_lft ตลอดไป
4: veth0@peer0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP กลุ่มเริ่มต้น qlen 1000
    ลิงค์/อีเธอร์ 4e:43:26:75:10:11 brd ff:ff:ff:ff:ff:ff
    ลิงค์ขอบเขต inet6 fe80::4c43:26ff:fe75:1011/64
       valid_lft ตลอดไป reserved_lft ตลอดไป
5: peer1@veth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP กลุ่มเริ่มต้น qlen 1000
    ลิงค์/อีเธอร์ ea:8c:82:e6:2e:a9 brd ff:ff:ff:ff:ff:ff
    inet6 cd::/128 ขอบเขตทั่วโลก
       valid_lft ตลอดไป reserved_lft ตลอดไป
    ลิงค์ขอบเขต inet6 fe80::e88c:82ff:fee6:2ea9/64
       valid_lft ตลอดไป reserved_lft ตลอดไป
6: veth1@peer1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP กลุ่มเริ่มต้น qlen 1000
    ลิงค์/อีเธอร์ da:5a:68:b1:e8:43 brd ff:ff:ff:ff:ff:ff
    ลิงค์ขอบเขต inet6 fe80::d85a:68ff:feb1:e843/64
       valid_lft ตลอดไป reserved_lft ตลอดไป

และเส้นทาง:

$ ไอพีอาร์
เริ่มต้นผ่าน 10.0.2.2 dev enp0s3 โปรโต dhcp src 10.0.2.15 เมตริก 100
10.0.2.0/24 dev enp0s3 โปรโตเคอร์เนลขอบเขตลิงก์ src 10.0.2.15
10.0.2.2 dev enp0s3 proto dhcp ขอบเขตลิงค์ src 10.0.2.15 เมตริก 100

ตอนนี้ฟัง peer0 บนพอร์ต UDP 2000:

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

และส่งแพ็กเก็ตผ่าน peer1:

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

และการฟัง เอ็นซี พิมพ์ เอบีซี! แต่ ทำไม? เพียร์0 และ เพื่อน1 ไม่ได้เชื่อมต่อกันแต่อย่างใด ถ้าเข้าใจถูกก็รับฟัง เอ็นซี ควรผูกพันกับ เพียร์0 และส่ง เอ็นซี ควรผูกพันกับ เพื่อน1.

Score:1
ธง cl
A.B

peer0 และ peer1 ไม่ได้เชื่อมต่อ แต่อย่างใด

เป็นอินเทอร์เฟซทั้งหมดของระบบ ดังนั้นจึงเชื่อมต่อกับระบบ การกำหนดเส้นทางเกิดขึ้นบนระบบระบบจะสื่อสารระหว่างแอดเดรสที่เป็นของตนเองโดยตรง โดยไม่มีการกำหนดเส้นทางแพ็กเก็ตภายนอก กล่าวคือไม่มีการส่งแพ็กเก็ตผ่านอินเทอร์เฟซ veth แต่ใช้อินเทอร์เฟซย้อนกลับ (พัฒนาเลย ด้านล่าง):

# เส้นทาง ip รับจาก cd:: ถึง ab::
local ab:: from cd:: dev lo table local proto kernel src ab:: metric 0 pref สื่อ

นอกจากนี้ มันไม่ได้ช่วยอะไรมากที่นี่ แต่เมื่อแสดงเส้นทางที่ไม่มีค่า IPv6 เพื่อบอกใบ้ IPv6 -6 จะต้องได้รับหรือค่าเริ่มต้นเป็น IPv4

เส้นทาง # ip -6
ab:: dev peer0 เคอร์เนลโปรโตเมตริก 256 pref สื่อ
cd:: dev peer1 โปรโตเคอร์เนลเมตริก 256 pref สื่อ
fe80::/64 dev peer1 โปรโตเคอร์เนลเมตริก 256 pref สื่อ
fe80::/64 dev veth1 โปรโตเคอร์เนลเมตริก 256 pref สื่อ
fe80::/64 dev peer0 เคอร์เนลโปรโตเมตริก 256 pref สื่อ
fe80::/64 dev veth0 เคอร์เนลโปรโตเมตริก 256 pref สื่อ
# ตารางแสดงเส้นทาง ip -6 ในพื้นที่
local ::1 dev lo proto kernel metric 0 pref สื่อ
local fe80::4c43:26ff:fe75:1011 dev veth0 proto kernel metric 0 pref สื่อ
local fe80::6c8d:c0ff:fe7c:29c dev peer0 โปรโตเคอร์เนลเมตริก 0 สื่อ pref
local fe80::d85a:68ff:feb1:e843 dev veth1 proto kernel metric 0 pref สื่อ
local fe80::e88c:82ff:fee6:2ea9 dev peer1 โปรโตเคอร์เนลเมตริก 0 สื่อ pref
มัลติคาสต์ ff00::/8 dev veth1 โปรโตเคอร์เนลเมตริก 256 pref สื่อ
มัลติคาสต์ ff00::/8 dev peer1 โปรโตเคอร์เนลเมตริก 256 pref สื่อ
มัลติคาสต์ ff00::/8 dev veth0 โปรโตเคอร์เนลเมตริก 256 pref สื่อ
มัลติคาสต์ ff00::/8 dev peer0 โปรโตเคอร์เนลเมตริก 256 pref สื่อ
ua flag
ขอบคุุณ. ดังนั้นเพื่อแยกพวกเขาฉันต้องใช้เนมสเปซเครือข่ายแยกกัน
A.B avatar
cl flag
A.B
ฉันไม่รู้แน่ชัดว่าคุณตั้งใจจะทำอะไรและเหตุใดจึงมีอินเทอร์เฟซ veth สองคู่แทนที่จะเป็นเพียงคู่เดียว แต่ใช่การใช้งานหลักของอินเทอร์เฟซ veth นั้นข้ามเนมสเปซเครือข่าย (มีการใช้งานทั่วไปน้อยกว่าในเนมสเปซเดียวกันเมื่อ ใช้สะพานด้วย)

โพสต์คำตอบ

คนส่วนใหญ่ไม่เข้าใจว่าการถามคำถามมากมายจะปลดล็อกการเรียนรู้และปรับปรุงความสัมพันธ์ระหว่างบุคคล ตัวอย่างเช่น ในการศึกษาของ Alison แม้ว่าผู้คนจะจำได้อย่างแม่นยำว่ามีคำถามกี่ข้อที่ถูกถามในการสนทนา แต่พวกเขาไม่เข้าใจความเชื่อมโยงระหว่างคำถามและความชอบ จากการศึกษาทั้ง 4 เรื่องที่ผู้เข้าร่วมมีส่วนร่วมในการสนทนาด้วยตนเองหรืออ่านบันทึกการสนทนาของผู้อื่น ผู้คนมักไม่ตระหนักว่าการถามคำถามจะมีอิทธิพลหรือมีอิทธิพลต่อระดับมิตรภาพระหว่างผู้สนทนา