แฮนด์เชกของ WireGuard ทำงาน แต่ซับเน็ตของออฟฟิศไม่ตอบสนอง

แฮนด์เชกเสร็จสิ้น wg show รายงานการรับส่งข้อมูลล่าสุด และที่อยู่ทันเนลของเซิร์ฟเวอร์ตอบสนองต่อ ping แต่โฮสต์ใน LAN ของเซิร์ฟเวอร์กลับไม่ตอบ ต้องเป็นจริงพร้อมกันสามเงื่อนไข ไคลเอนต์ต้องกำหนดเส้นทางคำนำหน้า LAN เข้าไปในทันเนล เซิร์ฟเวอร์ต้องส่งต่อแพ็กเก็ต และคำตอบต้องมีเส้นทางกลับ เมื่อขาดอย่างใดอย่างหนึ่ง อาการจะเหมือนกันทุกประการ

AllowedIPs เป็นทั้งรายการควบคุมการเข้าถึงและตารางเส้นทาง

บนไคลเอนต์ รายการ AllowedIPs กำหนดทั้งสิ่งที่อนุญาตให้ส่งไปยังพีียร์นั้นและเส้นทางที่ WireGuard ติดตั้ง รายการพีียร์ที่ระบุเพียงที่อยู่ทันเนลของเซิร์ฟเวอร์จะติดตั้งเส้นทางโฮสต์เดียว ดังนั้นปลายทางใน LAN จึงไม่เคยเข้าทันเนล การเพิ่มคำนำหน้า LAN เป็นสิ่งแรกที่ต้องตรวจสอบ และยังเป็นการเปลี่ยนแปลงที่มักหายไปบ่อยที่สุดหลังคัดลอกการกำหนดค่า พีียร์ที่ขยายเป็นเส้นทางเริ่มต้นเป็นดีไซน์อีกแบบ และจะย้ายทราฟฟิกอินเทอร์เน็ตของไคลเอนต์ด้วย

เก็บเส้นทางโฮสต์และคำนำหน้า LAN เป็นรายการแยกกัน หากออฟฟิศมีสองซับเน็ต ทั้งสองอยู่ในรายการ และคำนำหน้าที่สองที่หายไปทำให้เกิดความล้มเหลวที่ดูเหมือนเลือกเป็นบางส่วนมากกว่าทั้งหมด

[Peer]
PublicKey = <server public key>
Endpoint = vpn.example.net:51820
AllowedIPs = 10.66.0.1/32, 192.168.50.0/24

การส่งต่อและการแปลที่อยู่เป็นหน้าที่ของเซิร์ฟเวอร์

เซิร์ฟเวอร์ต้องเปิดการส่งต่อ IP มีกฎการส่งต่อที่รับทราฟฟิกจากทันเนล และมีกฎการแปลที่อยู่ไปยังอินเทอร์เฟซ LAN การแปลที่อยู่คือสิ่งที่ทำให้ดีไซน์ทำงานได้โดยไม่ต้องแตะทุกโฮสต์ในเครือข่ายออฟฟิศ คำตอบจึงกลับไปที่เซิร์ฟเวอร์แทนที่จะไปยังที่อยู่ที่ LAN ไม่เคยได้ยิน หากไม่มี การแปลนี้ ทุกโฮสต์ต้องมีเส้นทางไปยังซับเน็ตของทันเนลและกฎไฟร์วอลล์ที่อนุญาต ซึ่งแทบไม่เป็นที่ยอมรับในเครือข่ายที่คนอื่นดูแล

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i wg0 -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

กฎที่เพิ่มด้วยมือจะหายไปเมื่อรีบูต ดังนั้นผูกกฎกับอินเทอร์เฟซด้วยคำสั่ง hook ในการกำหนดค่าเซิร์ฟเวอร์ ชุดกฎที่อยู่ได้นานกว่าอินเทอร์เฟซของมันคือสาเหตุที่เครื่องหนึ่งลงเอยด้วยการแปลทราฟฟิกให้ทันเนลที่ไม่มีอยู่แล้ว

เมื่อ LAN ย้ายแต่กฎไม่ได้ย้าย

การเปลี่ยนเราเตอร์ที่กำหนดเลขซับเน็ตออฟฟิศใหม่คือรูปแบบคลาสสิกของความล้มเหลวนี้ ทันเนลยังทำงานอยู่ แฮนด์เชกยังสดใหม่ และไม่มีอะไรหลังเซิร์ฟเวอร์ตอบกลับ เพราะกฎการแปลยังระบุที่อยู่เก่า สคริปต์ติดตั้งมักฝังที่อยู่ LAN ของเซิร์ฟเวอร์ไว้ในกฎ POSTROUTING และหลังการกำหนดเลขใหม่ที่อยู่นั้นไม่มีอยู่บนอินเทอร์เฟซใดเลย แพ็กเก็ตจึงถูกเขียนใหม่ไปยังปลายทางที่ไม่สามารถตอบได้

iptables -t nat -n -L POSTROUTING
ip -br addr show

เปรียบเทียบผลลัพธ์ทั้งสอง เป้าหมายการแปลที่ไม่อยู่ในรายการอินเทอร์เฟซคือบั๊ก และการแก้ไขคือการเปลี่ยนหนึ่งบรรทัดเมื่อคุณเห็นมันแล้ว กฎอาจอยู่ใน unit ที่สร้างขึ้นแทนที่จะอยู่ในการกำหนดค่า WireGuard ดังนั้นโหลด unit นั้นใหม่หลังแก้ไข และยืนยันว่าการบูตครั้งถัดไปไม่เขียนทับการเปลี่ยนแปลงของคุณ

สองไซต์หลัง NAT ต้องมีจุดนัดพบ

เมื่อทั้งสองฝ่ายไม่รับการเชื่อมต่อขาเข้า คำตอบที่ใช้ได้จริงคือโฮสต์ขนาดเล็กที่มีที่อยู่สาธารณะและอินเทอร์เฟซ WireGuard สองอัน แต่ละไซต์เชื่อมต่อออกไป โฮสต์ตรงกลางระบุ LAN ของแต่ละพีียร์ใน AllowedIPsของตัวเอง และการส่งต่อนำแพ็กเก็ตระหว่างสองทันเนล ไม่มีอะไรในไฟร์วอลล์ของทั้งสองไซต์ต้องเปลี่ยน นั่นคือเหตุผลที่ดีไซน์นี้แพร่หลายได้ง่าย

การกำหนดเส้นทางระหว่างไซต์ยังคงที่อยู่ต้นทางเดิม และทำให้การบันทึกต่อโฮสต์ยังมีความหมาย การแปลที่อยู่บนโฮสต์ตรงกลางง่ายกว่าเมื่อสอง LAN ทับซ้อนกัน แต่ต้องแลกกับการสูญเสียตัวตนของต้นทางในบันทึก ตัดสินใจว่าคุณสมบัติใดสำคัญก่อนเลือก

แยกชั้นด้วยการตรวจสอบสี่อย่าง

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

wg show
ip route get 192.168.50.20
tcpdump -ni wg0 icmp
iptables -vnL FORWARD --line-numbers

คำขอที่มาถึงแต่ไม่ก่อให้เกิดคำตอบชี้ไปที่เส้นทางของคำตอบหรือโฮสต์ใน LAN คำขอที่ไม่เคยมาถึงชี้ไปที่ AllowedIPs หรือเส้นทางของไคลเอนต์ ผลลัพธ์สองอย่างนี้ต้องแก้ต่างกัน และการดักจับแพ็กเก็ตคือสิ่งที่แยกความต่างนั้น