Score:2

การสั่งซื้อการกำหนดค่าอินเทอร์เฟซด้วย systemd-networkd

ธง pl

ฉันใช้ Ubuntu 20.04 กับ systemd-networkd และ Netplan ฉันมีสองอินเทอร์เฟซทางกายภาพ (ens3 และ ens4) ซึ่งกำหนดค่าโดย DHCP (มีการจอง ดังนั้นฉันจึงได้รับที่อยู่เดิมเสมอ)

นอกจากนี้ ฉันมีอุปกรณ์อุโมงค์สองเครื่อง สิ่งเหล่านี้อยู่นอกการควบคุมของ Netplan/networkd (สร้างขึ้นโดย Strongswan แต่สำหรับจุดประสงค์และวัตถุประสงค์ทั้งหมด สิ่งเหล่านี้ถูกสร้างขึ้นด้วยตนเองโดยการเรียกใช้บางอย่างเช่น ip อุโมงค์เพิ่ม...). อุปกรณ์อุโมงค์เหล่านี้มี เส้นทางไอพี เพิ่มเพื่อส่งการเข้าชมให้กับพวกเขา เมื่อสร้างครั้งแรกสิ่งเหล่านี้ทำงานได้ดี แต่ systemd-networkd จะลบเส้นทางออกในที่สุด

เพื่อตอบโต้สิ่งนี้ ฉันได้กำหนดค่าอุปกรณ์ช่องสัญญาณใน systemd-networkd สำเร็จแล้ว แต่สร้างเส้นทางไม่สำเร็จเนื่องจากมีการพยายามก่อน ens3/ens4 มีการกำหนดค่า (ฉันเห็น อุโมงค์ 1: ไม่สามารถกำหนดเส้นทาง: ที่อยู่ prefsrc ไม่ถูกต้อง อาร์กิวเมนต์ไม่ถูกต้อง ใน syslog) ฉันได้ยืนยันการสั่งซื้อโดยการเปิดสวิตช์ การบันทึกการแก้ปัญหา.

ฉันสามารถเพิ่มเส้นทางด้วยตนเอง:

เส้นทาง ip เพิ่ม 10.0.32.0/20 dev tunnel1 ลิงค์ขอบเขต src 10.0.16.170 เมตริก 100

... ซึ่งใช้งานได้ดี แต่จะถูกลบออกในภายหลังโดย systemd-networkd

เดอะ เอกสาร ระบุว่า "ไฟล์การกำหนดค่าทั้งหมดถูกจัดเรียงและประมวลผลโดยรวมตามลำดับคำศัพท์ โดยไม่คำนึงว่าไฟล์เหล่านั้นอยู่ในไดเร็กทอรีใด" ดังนั้นฉันจึงค้นหาไฟล์กำหนดค่าอื่นๆ และพบไฟล์เหล่านี้ใน /run/systemd/network:

10-netplan-ens3.link
10-netplan-ens3.network
10-netplan-ens4.link
10-netplan-ens4.network

ฉันได้ลองตั้งชื่อของฉันแล้ว เน็ตเดฟ และ เครือข่าย ไฟล์เป็น 99-tunnel1.netdev หรือ zzzz-tunnel1.netdev ฯลฯ และแม้แต่ลองด้วย 00- ฯลฯ ด้วย ไม่ว่าฉันจะทำอะไรก็ดูเหมือนจะเป็นอย่างนั้นเสมอ ens3 และ ens4 ได้รับการกำหนดค่าหลังจากอินเทอร์เฟซทันเนล ดังนั้นเส้นทางจึงไม่สามารถเพิ่มได้เสมอ

ฉันได้ลองกำหนดค่าอุปกรณ์ของฉันใน Netplan แล้ว มันทำให้บางสิ่งยุ่งยาก แต่ท้ายที่สุดก็มีปัญหาเดียวกัน แม้ว่าจะสร้างไฟล์เช่น 10-netplan-tunnel1.network (ซึ่งเป็นศัพท์ตามหลังไฟล์ ens3/ens4) พวกเขายังคงใช้ลำดับที่ไม่ถูกต้องโดย networkd

ฉันแน่ใจว่าฉันพลาดบางอย่างที่นี่ แต่ฉันไม่เห็นอะไร ความคิดใด ๆ ?

ของฉัน อุโมงค์1.netdev มีลักษณะดังนี้:

[เน็ตเดฟ]
ชื่อ=อุโมงค์1
ชนิด = vti
MTUBytes=1419

[อุโมงค์]
รีโมท=1.2.3.4
ท้องถิ่น=2.3.4.5
คีย์=100

...และ .เครือข่าย มีลักษณะดังนี้:

[จับคู่]
ชื่อ=อุโมงค์1

[ลิงค์]
จำเป็นสำหรับออนไลน์=ไม่
MTUBytes=1419

[ที่อยู่]
ที่อยู่=169.254.102.162/30
เพื่อน=169.254.102.161/30

[เส้นทาง]
ปลายทาง=10.0.32.0/20
PreferredSource=10.0.16.170
เมตริก=100
ขอบเขต=ลิงค์
us flag
ความคาดหวังคือ networkd จะไม่สัมผัสการกำหนดค่า รวมถึงเส้นทาง บนอุปกรณ์ที่ไม่ได้รับการแจ้งเตือน แต่ฉันสงสัยว่าเป็นเคอร์เนลที่ลบเส้นทางให้คุณโดยอัตโนมัติหรือไม่ ฉันสังเกตเห็นว่าเส้นทางที่เป็นปัญหามีการระบุ 'src' ซึ่งไม่ใช่ IP ที่แสดงรายการว่าเชื่อมโยงกับอินเทอร์เฟซ (และดังนั้น ฉันไม่คาดหวังว่าเส้นทางนี้จะทำงานจริงตามที่กำหนดไว้) พฤติกรรมที่คุณคาดหวังจากสิ่งนี้คืออะไร เนื่องจาก 10.0.16.170 ไม่ใช่ที่อยู่ IP บนอินเทอร์เฟซ
pl flag
ฉันยอมรับว่า networkd ไม่ควรยุ่งกับสิ่งที่ไม่ได้กำหนดค่าไว้ อย่างไรก็ตาม ใช่ เส้นทางมี src ซึ่งอยู่บนอินเทอร์เฟซที่จัดการโดยเครือข่าย ดังนั้นเส้นทางจะต้องออกมาเมื่ออินเทอร์เฟซ "หยุดทำงาน" (แต่มิฉะนั้น เส้นทางก็จำเป็นและทำงานได้ดี) สิ่งที่น่าสงสัยคือเมื่อกำหนดค่าอุปกรณ์ `ens` และ `tunnel` (vti) networkd ยืนยันที่จะทำอุโมงค์ก่อน - ซึ่งฉันนึกไม่ออกว่าจะถูกต้องโดยเฉพาะอย่างยิ่งหากกำหนดค่าให้ทำครั้งสุดท้าย - และฉันก็ไม่ ดูเหมือนจะไม่สามารถเปลี่ยนพฤติกรรมนั้นได้
Nate T avatar
it flag
คุณช่วยเขียนเชลล์สคริปต์เพื่อกำหนดค่าในแบบแมนวล แล้วตั้งค่างาน cron เพื่อตรวจสอบเส้นทางได้ไหม หากไม่มีเส้นทางอยู่ ก็จะไม่สามารถเรียกใช้สคริปต์ได้ใช่หรือไม่ หรือกำหนดค่าใหม่ด้วยวิธีที่คุณเลือก? ฉันใช้ network mgr ผ่าน nmcli เพื่อ reconf แต่ของฉันขาด ๆ หาย ๆ และนี่คือวิธีที่ฉันจัดการกับมัน
pl flag
ขอบคุณสำหรับความคิด แต่ฉันไม่ใช่แฟนของโซลูชันสคริปต์ cron - หากเส้นทางถูกลบหลังจากสคริปต์ทำงาน จะมีการหยุดทำงานหนึ่งนาทีจนกว่าสคริปต์จะทำงานอีกครั้ง ไม่ต้องพูดถึงการเรียกใช้สคริปต์เป็นพันๆ ครั้งโดยไม่จำเป็น เป็นวิธีแก้ปัญหาสุดท้ายและฉันคิดว่าการดึง systemd ออกจะมาก่อน
Score:1
ธง cn

ฉันคิดว่าเรามีปัญหาสองประการที่นี่:

1/ การลบเส้นทาง src ของคุณอาจเกิดจากการสูญเสียของพาหะเป็นระยะๆ บนอินเทอร์เฟซ ens3/4 เมื่ออินเทอร์เฟซหยุดทำงาน (แม้เพียงช่วงสั้นๆ) มันจะล้างที่อยู่ IP และเส้นทาง src ที่เกี่ยวข้องกับที่อยู่ IP นี้ด้วย จากนั้นจะกำหนดค่า IP ใหม่ผ่าน DHCP แต่สูญเสียเส้นทาง src ที่คุณเพิ่มด้วยตนเอง ลองสร้างดรอปอินแทนที่การกำหนดค่า เช่น: /etc/systemd/network/10-netplan-ens3.network.d/override.conf:

[เครือข่าย]
ConfigureWithoutCarrier=จริง
IgnoreCarrierLoss=จริง

2/ systemd-networkd ประมวลผลไฟล์ .network ตามลำดับคำศัพท์ แต่ที่อยู่ IP ที่ DHCP ให้มานั้นจะได้รับแบบอะซิงโครนัสเท่านั้นหลังจากได้รับสัญญาเช่า DHCP networkd ไม่บล็อกการกำหนดค่าของอินเทอร์เฟซอื่นๆ (เช่น อินเทอร์เฟซช่องสัญญาณของคุณ) ในการตอบสนอง DHCP นี้ ดังนั้นจึงไม่สามารถเพิ่มเส้นทางได้ เนื่องจาก src IP นั้นยังไม่มีอยู่ในขณะนั้น

คุณบอกว่าคุณมีการกำหนดค่าที่ให้ที่อยู่ IP เดียวกันเสมอผ่าน DHCP ทำไมคุณไม่ระบุที่อยู่ IP เดียวกันนี้แบบคงที่ (เช่น ที่อยู่: [10.0.16.170/30] ใน netplan âหรือ netmask คืออะไร) ด้วยวิธีนี้ networkd ควรจะเพิ่มของคุณ แหล่งที่ต้องการ= ที่อยู่โดยไม่มีปัญหาและกำหนดค่าใหม่หลังจากผู้ให้บริการสูญหาย

pl flag
การสูญเสียผู้ให้บริการฟังดูเป็นสาเหตุที่เป็นไปได้มากสำหรับปัญหา - ฉันไม่ได้คิดถึงเรื่องนั้นและจะทำให้เกิดปัญหาทั้งหมดที่คุณกล่าวถึง ธรรมชาติที่ไม่ปิดกั้นของ networkd ดูเหมือนจะเป็นปัญหาของฉัน - ฉันคิดว่าไม่มีทางที่จะพูดว่า "รอจนกว่าจะกำหนดค่า" หรือ "อย่าทำสิ่งนี้จนกว่า X จะเสร็จสิ้น" แต่ฉันสามารถใช้ IP คงที่ได้ - นั่น เกือบจะแก้ปัญหาได้อย่างแน่นอน (แม้ว่าจะยกคนอื่น ๆ เช่นการแก้ไข DNS - แต่นั่นก็แก้ไขได้ง่ายเช่นกันในสภาพแวดล้อมของฉัน) ขอบคุณมากสำหรับความคิด - มีประโยชน์จริงๆ (ในทางเทคนิคและสำหรับสติของฉัน!)

โพสต์คำตอบ

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