WireGuard ส่งข้อมูลแต่ไม่ได้รับอะไรกลับมา: ฝั่งไหน
ตัวนับการส่งที่เพิ่มขึ้นบอกทิศทาง ไม่ใช่การวินิจฉัย ตัดสินว่าคำขอไม่เคยออกจากทันเนลหรือคำตอบไม่เคยย้อนกลับมาก่อนแก้ไขสิ่งใด
ตัวนับการส่งที่เพิ่มขึ้นในขณะที่ตัวนับการรับยังคงเป็นศูนย์บอกทิศทาง ไม่ใช่การวินิจฉัย อาการอ่านแบบเดียวกันนี้ปรากฏเมื่อเพียร์ไม่เคยจับมือเสร็จ เมื่อปลายทางเลือกเพียร์ผิด เมื่อฝั่งไกลไม่มีเส้นทางย้อนกลับ และเมื่อฟิลเตอร์ทิ้งคำตอบระหว่างทางกลับบ้าน แต่ละกรณีแก้ไขคนละที่
การเปรียบเทียบที่ทำให้งานสั้นลงคือคำขอที่ไม่เคยออกจากทันเนลกับคำตอบที่ไม่เคยย้อนกลับมา การดักจับหนึ่งครั้งบนอินเทอร์เฟซที่ถูกต้องเป็นตัวตัดสินระหว่างสองกรณี
ตัวนับบอกปริมาณ ไม่ใช่ทิศทางของปัญหา
ตัวนับของ WireGuard บันทึกว่าอินเทอร์เฟซมอบอะไรให้เพียร์และได้รับอะไรจากเพียร์ มันไม่บอกว่าปลายทางใด เพียร์ใด หรือครึ่งใดของการแลกเปลี่ยนที่ล้มเหลว ทราฟฟิกพื้นหลังทำให้ยอดรวมยิ่งไม่มีความหมาย เพราะบางไบต์อาจเป็นข้อความคงการเชื่อมต่อหรือโฟลว์ที่ไม่เกี่ยวข้อง อ่านมันเป็นสัญญาณว่าอินเทอร์เฟซยังทำงานอยู่ แล้วเลิกใช้เป็นหลักฐาน
ข้อเท็จจริงแรกที่มีประโยชน์คือการจับมือยังสดอยู่หรือไม่ หากไม่มี จะไม่มีอะไรถูกเข้ารหัสสำหรับเพียร์นี้ และตัวนับการรับก็ไม่มีเหตุให้ขยับ
การเลือกเพียร์หรือเส้นทางของคำตอบ: สองคำอธิบาย
คำอธิบายแรกคือแพ็กเก็ตไม่เคยไปถึงเพียร์ที่ตั้งใจ เพราะเส้นทางชี้ไปที่อื่นหรือพรีฟิกซ์ที่อนุญาตของเพียร์ไม่ครอบคลุมปลายทาง คำอธิบายที่สองคือแพ็กเก็ตไปถึงแต่คำตอบย้อนกลับไม่ได้ ซึ่งเป็นปัญหาเส้นทางที่ปลายไกล ตารางแยกสองกรณีนี้ออกจากกันด้วยสิ่งที่คุณจะเห็นในแต่ละจุด
| Observation | Points to |
|---|---|
| No handshake while transmit climbs | Peer selection or endpoint |
| Handshake current, request visible on the server | Reply path or far-side route |
| Request never visible on the server | Allowed prefixes or local route |
| Both packets visible, nothing reaches the client | Return filter or translation |
อ่านตารางจากบนลงล่าง การไม่มีข้อมูลจับมือทำให้คุณไปดูคีย์ จุดปลายทาง และเส้นทางภายนอก เพราะยังไม่มีอะไรอื่นให้ตรวจ การจับมือที่สดอยู่พร้อมคำขอที่เห็นได้บนเซิร์ฟเวอร์ย้ายปัญหาไปยังทิศทางย้อนกลับ ซึ่งตารางเส้นทางของปลายทางเองเป็นตัวตัดสิน คำขอที่ไม่เคยปรากฏบนเซิร์ฟเวอร์เลยคือปัญหาเรื่องการเลือก และพรีฟิกซ์ที่อนุญาตบนเพียร์ทั้งสองคือสิ่งแรกที่ต้องเปรียบเทียบ
สองในสี่แถวนี้แก้ที่ไคลเอนต์และอีกสองแก้ที่เซิร์ฟเวอร์ การรู้ว่าคุณอยู่ในคู่ไหนคืองานส่วนใหญ่
คำตอบหายไปที่ใด
คำตอบออกจากปลายทาง มาถึงอินเทอร์เฟซทันเนลของเซิร์ฟเวอร์ และถูกเข้ารหัสสำหรับเพียร์ที่ที่อยู่ที่อนุญาตตรงกับที่อยู่ภายในของไคลเอนต์ หากการจับคู่นั้นล้มเหลว คำตอบจะถูกทิ้งอย่างเงียบ ๆ ซึ่งจากฝั่งไคลเอนต์ดูเหมือนปัญหาของเครือข่ายทุกประการ หากคำตอบถูกเข้ารหัสและฟิลเตอร์ของไคลเอนต์เองปฏิเสธ อาการก็เหมือนเดิมอีกครั้ง ทั้งสองกรณีต้องใช้การดักจับ ไม่ใช่ตัวนับ
รูปแบบที่รุนแรงที่สุดของความผิดพลาดนี้คือเซิร์ฟเวอร์ที่ส่งต่อแพ็กเก็ตให้ไคลเอนต์แต่ไม่มีเส้นทางย้อนกลับไปยังช่วงภายในของไคลเอนต์ มันรับคำขอ ส่งคำตอบไปยังเกตเวย์เริ่มต้นของตน และทันเนลไม่เคยเห็นมัน กฎการแปลที่กว้างเกินไปซึ่งเพิ่มบนเซิร์ฟเวอร์กลับซ่อนปัญหานั้นแทนที่จะแก้เส้นทาง
ทดสอบปลายทางเดียวตั้งแต่ต้นจนจบ
เลือกปลายทางเดียวภายในช่วงของเพียร์ และทดสอบในขณะที่การจับมือสดอยู่ชัดเจน คำสั่งด้านล่างอ่านสถานะของเพียร์ เส้นทางที่เลือก และทั้งสองด้านของการแลกเปลี่ยน รันการดักจับบนอินเทอร์เฟซที่แพ็กเก็ตที่เข้ารหัสใช้จริง
wg show wg0 latest-handshakes
wg show wg0 transfer
ip route get 10.60.9.5
sudo tcpdump -ni wg0 host 10.60.9.5การดักจับที่แสดงคำขอบนอินเทอร์เฟซทันเนลโดยไม่มีอะไรย้อนกลับมา คือคำตอบจากฝั่งเซิร์ฟเวอร์ และ ตารางเส้นทางของปลายทางคือที่ต่อไปที่ต้องดู หากไม่มีอะไรปรากฏเลย แพ็กเก็ตไปอีกเส้นทางหนึ่ง ดังนั้นเส้นทางภายในเครื่องคือผู้ต้องสงสัย การแลกเปลี่ยนที่เห็นในการดักจับทั้งสองครั้งแต่ไม่มีความคืบหน้าในแอปพลิเคชัน ย้ายคำถามไปที่ขนาดแพ็กเก็ตหรือฟิลเตอร์ที่สถิติอินเทอร์เฟซไม่เคยแสดง เก็บปลายทางเดียวและไคลเอนต์เดียวไว้ในการทดสอบ เพราะตัวแปรที่สองเปลี่ยนหลักฐานกลับเป็นความรู้สึก
หากชื่อล้มเหลวในขณะที่ที่อยู่ที่อนุญาตใช้งานได้ คำตอบอยู่ใน DNS ไม่ใช่ในทันเนล หากเฉพาะการถ่ายโอนขนาดใหญ่ติดขัด ให้ตรวจขนาดแพ็กเก็ตแยกต่างหาก