Score:2

site2site wireguard พร้อมนักเทียบท่า: ปัญหาการกำหนดเส้นทาง

ธง fr

ข้อจำกัดความรับผิดชอบ: โพสต์ใหม่จาก stackoverflow: https://stackoverflow.com/questions/67917278/site2site-wireguard-with-docker-routing-problems

ฉันกำลังพยายามมีคอนเทนเนอร์สองคอนเทนเนอร์ ทำงานบน RPI สองรายการ ทำหน้าที่เป็น VPN แบบไซต์ต่อไซต์ระหว่างเครือข่ายที่ 1 และเครือข่ายที่ 2

ด้วยการตั้งค่าด้านล่าง ฉันสามารถ ping ได้ จากภายในคอนเทนเนอร์ เครือข่ายซึ่งกันและกัน:

  • จาก docker container 1 ฉันสามารถ ping ที่อยู่ 192.168.1.1
  • จาก docker container 2 ฉันสามารถ ping ที่อยู่ 192.168.10.1

แต่ถ้าฉันพยายาม ping 192.168.1.1 จากโฮสต์ System1 (192.168.10.100) ฉันมีข้อผิดพลาด (ดูภาพด้านล่างเพื่อให้เห็นภาพสิ่งที่ฉันพยายามทำ)

ฉันเข้าใจว่าฉันต้องเพิ่มเส้นทางแบบคงที่บนโฮสต์ system1 (192.168.10.100) เพื่อกำหนดเส้นทางการรับส่งข้อมูลสำหรับ 192.168.1.0/24 ผ่านคอนเทนเนอร์ wireguard (172.17.0.5) ดังนั้นฉันจึงเรียกใช้:

เส้นทาง $i p เพิ่ม 192.168.1.0/24 ผ่าน 172.17.0.5
เส้นทาง $ ip
ค่าเริ่มต้นผ่าน 192.168.10.1 dev eth0 proto dhcp src 192.168.10.100 เมตริก 100 
172.17.0.0/16 dev docker0 proto kernel ขอบเขตลิงค์ src 172.17.0.1 
172.18.0.0/16 dev br-e19a4f1b7646 โปรโตเคอร์เนลขอบเขตลิงก์ src 172.18.0.1 ลิงก์ดาวน์ 
172.19.0.0/16 dev br-19684dacea29 โปรโตเคอร์เนลขอบเขตลิงก์ src 172.19.0.1 
172.20.0.0/16 dev br-446863cf7cef โปรโตเคอร์เนลขอบเขตลิงก์ src 172.20.0.1 
172.21.0.0/16 dev br-6800ed9b4dd6 ขอบเขตเคอร์เนลโปรโต ลิงก์ src 172.21.0.1 ลิงก์ดาวน์ 
172.22.0.0/16 dev br-8f8f439a7a28 ขอบเขตเคอร์เนลโปรโต ลิงก์ src 172.22.0.1 ลิงก์ดาวน์ 
192.168.1.0/24 ผ่าน 172.17.0.5 dev docker0 
192.168.10.0/24 dev eth0 ลิงก์ขอบเขตเคอร์เนลโปรโต src 192.168.10.100 
192.168.10.1 dev eth0 proto dhcp ขอบเขตลิงก์ src 192.168.10.100 เมตริก 100 

แต่การ ping ไปที่ 192.168.1.1 ยังคงล้มเหลว

ด้วยการรัน tcpdump บนคอนเทนเนอร์ 2 ฉันเห็นว่ามีบางแพ็กเก็ตถึงคอนเทนเนอร์จริง ๆ :

root@936de7c0d7eb:/# tcpdump -n -i ใด ๆ
tcpdump: เอาต์พุต verbose ถูกระงับ ใช้ -v หรือ -vv สำหรับการถอดรหัสโปรโตคอลแบบเต็ม
ฟัง LINUX_SLL ประเภทลิงก์ใด ๆ (Linux สุกแล้ว) ขนาดการจับภาพ 262144 ไบต์
10:11:19.885845 IP [publicIPsystem1].56200 > 172.17.0.6.56100: UDP ความยาว 128
10:11:30.440764 IP 172.17.0.6.56100 > [publicIPsystem1].56200: UDP ความยาว 32
10:11:35.480625 ARP, Request who-has 172.17.0.1 บอก 172.17.0.6 ความยาว 28
10:11:35.480755 ARP, ตอบกลับ 172.17.0.1 is-at 02:42:24:e5:ac:38, ยาว 28

ดังนั้นฉันเดาว่ามันไม่ใช่ปัญหาการกำหนดเส้นทางในระบบ 1

ใครช่วยบอกฉันทีว่าจะวินิจฉัยสิ่งนี้ต่อไปได้อย่างไร


แก้ไข 1:
ฉันได้ทำการทดสอบต่อไปนี้แล้ว:

  1. รัน 'tcpdump -ni any' บนคอนเทนเนอร์ 2
  2. ส่ง ping จากระบบ 1 (จากระบบโฮสต์) 'ping -c 1 192.168.1.1 .
    บนคอนเทนเนอร์ 2 tcpdump บันทึกต่อไปนี้:
    tcpdump: เอาต์พุต verbose ถูกระงับ ใช้ -v หรือ -vv สำหรับการถอดรหัสโปรโตคอลแบบเต็ม
    ฟัง LINUX_SLL ประเภทลิงก์ใด ๆ (Linux สุกแล้ว) ขนาดการจับภาพ 262144 ไบต์
    15:04:47.495066 IP [publicIPsystem1].56200 > 172.17.0.3.56100: UDP ความยาว 128
    15:04:58.120761 IP 172.17.0.3.56100 > [publicIPsystem1].56200: UDP ความยาว 32
  1. ส่ง ping จากคอนเทนเนอร์ (ภายในคอนเทนเนอร์) ' ping -c 1 192.168.1.1 .
    บนคอนเทนเนอร์ 2 tcpdump บันทึกต่อไปนี้:
# tcpdump -ni ใด ๆ
tcpdump: เอาต์พุต verbose ถูกระงับ ใช้ -v หรือ -vv สำหรับการถอดรหัสโปรโตคอลแบบเต็ม
ฟัง LINUX_SLL ประเภทลิงก์ใด ๆ (Linux สุกแล้ว) ขนาดการจับภาพ 262144 ไบต์
15:05:48.120717 IP [publicIPsystem1].56200 > 172.17.0.3.56100: UDP ความยาว 128
15:05:48.120871 IP 10.13.18.2 > 192.168.1.1: คำขอเสียงสะท้อน ICMP, id 747, seq 1, ความยาว 64
15:05:48.120963 IP 172.17.0.3 > 192.168.1.1: คำขอเสียงสะท้อน ICMP, id 747, seq 1, ความยาว 64
15:05:48.121955 IP 192.168.1.1 > 172.17.0.3: ICMP echo reply, id 747, seq 1, length 64
15:05:48.122054 IP 192.168.1.1 > 10.13.18.2: ICMP echo reply, id 747, seq 1, length 64
15:05:48.122246 IP 172.17.0.3.56100 > [publicIPsystem1].56200: UDP ความยาว 128
15:05:53.160617 ARP, Request who-has 172.17.0.1 บอก 172.17.0.3 ยาว 28
15:05:53.160636 ARP, Request who-has 172.17.0.3 บอก 172.17.0.1 ความยาว 28
15:05:53.160745 ARP ตอบกลับ 172.17.0.3 is-at 02:42:ac:11:00:03, ความยาว 28
15:05:53.160738 ARP, ตอบกลับ 172.17.0.1 is-at 02:42:24:e5:ac:38, ยาว 28
15:05:58.672032 IP [publicIPsystem1].56200 > 172.17.0.3.56100: UDP ความยาว 32

ดังนั้นดูเหมือนว่าแพ็กเก็ตจะได้รับการปฏิบัติที่แตกต่างจากคอนเทนเนอร์ 2 ขึ้นอยู่กับบางสิ่งที่ฉันขาดหายไป .. อาจเป็นปัญหาของ iptables?


ป้อนคำอธิบายรูปภาพที่นี่

ไซต์ 1 ไซต์ 2
เครือข่าย 1 ช่วง IP 192.168.10.0/24 192.168.1.0/24
ที่อยู่ระบบโฮสต์ 192.168.10.100 192.168.1.100
ช่วงสะพานนักเทียบท่า 0 172.17.0.0/16 172.17.0.0/16
ที่อยู่คอนเทนเนอร์ 172.17.0.5 172.17.0.6

ระบบ 1 - wg0.conf

[อินเตอร์เฟซ]
ที่อยู่ = 10.13.18.2
คีย์ส่วนตัว = *คีย์ส่วนตัว*
ListenPort = 56200
PostUp = iptables -A FORWARD -i %i -j ยอมรับ; iptables -A ไปข้างหน้า -o %i -j ยอมรับ; iptables -t nat -A โพสต์ -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ยอมรับ; iptables -D ส่งต่อ -o %i -j ยอมรับ; iptables -t nat -D โพสต์ -o eth0 -j MASQUERADE

[เพียร์]
PublicKey = *พับลิกคีย์*
ปลายทาง = *system2address*:56100
AllowedIPs = 10.13.18.1/32 , 192.168.1.0/24

ระบบ 2 - wg0.conf

[อินเตอร์เฟซ]
ที่อยู่ = 10.13.18.1
ListenPort = 56100
คีย์ส่วนตัว = *คีย์ส่วนตัว*
PostUp = iptables -A FORWARD -i %i -j ยอมรับ; iptables -A ไปข้างหน้า -o %i -j ยอมรับ; iptables -t nat -A โพสต์ -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ยอมรับ; iptables -D ส่งต่อ -o %i -j ยอมรับ; iptables -t nat -D โพสต์ -o eth0 -j MASQUERADE

[เพียร์]
#peer_casaleuven
PublicKey = *พับลิกคีย์*
AllowedIPs = 10.13.18.2/32 , 192.168.10.0/24
ปลายทาง = *system1address*:56200
jabbson avatar
sb flag
เมื่อคุณ ping 192.168.1.1 จากระบบ 1 - คุณเห็นแพ็กเก็ตที่มาถึงคอนเทนเนอร์ 1 และปล่อยไว้ซึ่งคุณสามารถเชื่อมโยงกับแพ็กเก็ตขาเข้าที่คุณเห็นบนคอนเทนเนอร์ 2 (สาเหตุที่คุณเห็นอาจเป็นเพียงแค่ Keepalives หรือบางอย่าง)? WireGuard มีบันทึกใด ๆ ที่คุณสามารถดูได้หรือไม่? ตารางเส้นทางบนคอนเทนเนอร์ 1 มีลักษณะอย่างไร
fr flag
ใช่ ฉันได้พยายามเรียกใช้ 'tcpdump -ni any' บนคอนเทนเนอร์ทั้งสองพร้อมกัน โดยรอสองสามวินาทีเพื่อตรวจสอบว่าไม่มีการบันทึกแพ็กเก็ตอื่นๆ จากนั้นฉันเรียกใช้ 'ping -c 1 192.168.1.1' เพื่อส่ง ping เพียงหนึ่งครั้งจากระบบ 1 และฉันเห็นแพ็กเก็ตที่ส่งผ่านใน tcpdumps ทั้งสอง
fr flag
เพิ่มการทดสอบอื่นในส่วนแก้ไข 1
A.B avatar
cl flag
A.B
หมายเหตุ: ฉันหวังว่า `eth0` ของคอนเทนเนอร์จะไม่เกี่ยวข้องกัน เพราะไม่ควรมี NAT ที่ใดก็ได้ ดังนั้นฉันจึงไม่เข้าใจว่าเหตุใดจึงมีกฎนี้: `iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE` ภายใน `PostUp`
fr flag
กฎ iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE ถูกใส่โดยค่าเริ่มต้นโดย linuxserver/wireguard ในการกำหนดค่าเริ่มต้น หากฉันลบออกจากทั้ง PostUp และ PostDown ในคอนเทนเนอร์ทั้งสอง ฉันจะไม่สามารถ ping อะไรได้อีก
A.B avatar
cl flag
A.B
ตกลง. อย่างไรก็ตามสิ่งนี้จะไม่เปลี่ยนแปลงอะไรกับคำตอบที่ฉันเขียนไว้ด้านล่าง คุณลองหรือยัง
fr flag
ครับผมลองแล้วได้ผล!!! ขอบคุณมาก! ฉันสงสัยว่าทำไมกฎนั้นถึงเป็นพื้นฐานที่จะทำให้มันใช้งานได้ ถ้าฉันเรียกใช้ iptables --list ฉันไม่เห็นตาราง NAT เลย..
Score:1
ธง cl
A.B

ดูเหมือนว่าปัญหาการกำหนดเส้นทาง

192.168.1.0/24 ผ่าน 172.17.0.5 dev docker0

เส้นทางนี้ไม่ได้บอกใบ้ด้วยที่อยู่ต้นทางที่ต้องการ ดังนั้นโดยธรรมชาติแล้วโฮสต์จะเลือกที่อยู่ที่ใกล้เคียงที่สุด: 172.17.0.1 เนื่องจากเป็นที่อยู่หลักบน นักเทียบท่า0. 172.17.0.1 ไม่อยู่ในรายการ AllowedIPs ของเพียร์การ์ด (และไม่ควรเป็นเช่นนั้น) ดังนั้นจะถูกปฏิเสธโดย WireGuard หากไม่ได้รับการปฏิเสธ จะมีปัญหาการกำหนดเส้นทางในเพียร์เนื่องจาก LAN ทั้งสองแยกกันโดยใช้บล็อกที่อยู่ IP เดียวกัน

ลองสิ่งนี้

  • ระบบ 1

    เส้นทาง ip แทนที่ 192.168.1.0/24 ผ่าน 172.17.0.5 dev docker0 src 192.168.10.100
    
  • ระบบ 2

    เส้นทาง ip แทนที่ 192.168.10.0/24 ผ่าน 172.17.0.6 dev docker0 src 192.168.1.100
    

โปรดทราบว่าก่อนที่จะมีการปรับเปลี่ยนนี้ สิ่งนี้ไม่ควรส่งผลกระทบต่อ LAN ที่เหลือ เฉพาะกับระบบโฮสต์ Docker สองระบบเท่านั้น

A.B avatar
cl flag
A.B
อธิบายสิ่งที่ฉันเขียนในคำตอบอีกครั้ง: ที่อยู่ต้นทางที่เลือกผิด เส้นทางนี้มี src บอกใบ้ให้ใช้ที่อยู่ต้นทางที่ถูกต้องจาก LAN

โพสต์คำตอบ

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