WireGuard ไม่แสดงแฮนด์เชกครั้งล่าสุด: ควรตรวจอะไรก่อน

ฟิลด์แฮนด์เชกครั้งล่าสุดที่ว่างมักหมายความว่าอินเทอร์เฟซยังไม่ได้ทำแฮนด์เชกให้เสร็จตั้งแต่เริ่มทำงาน ซึ่งบอกเกี่ยวกับการกำหนดค่าน้อยกว่าที่เห็น WireGuard จะเงียบจนกว่าแพ็กเก็ตจะต้องออกผ่านอินเทอร์เฟซ ดังนั้น peer ที่ไม่ได้ใช้งานและไม่มีอะไรจะส่งจะรายงานเช่นนั้นทุกครั้ง ตรวจสอบให้แน่ใจว่ามีการเสนออะไรจริงก่อนที่จะตรวจคีย์

การทดสอบคือแพ็กเก็ตที่ได้รับอนุญาตไปยังปลายทางที่ peer ควรพาไป ส่วนอื่นทั้งหมดบนหน้าจอสถานะนั้นอธิบายความตั้งใจ ไม่ใช่กิจกรรม

อินเทอร์เฟซที่ไม่ใช้งานไม่มีอะไรจะรายงาน

WireGuard ทำแฮนด์เชกอย่างเกียจคร้าน: แพ็กเก็ตแรกที่ต้องใช้ทันเนลจะเริ่มการแลกเปลี่ยน และอินเทอร์เฟซจะเงียบจนถึงตอนนั้น peer ที่กำหนดค่าไว้แล้วแต่ไม่เคยใช้จะแสดงแฮนด์เชกว่าง ไบต์ที่รับเป็นศูนย์ และช่องว่างที่เพิ่มขึ้นตั้งแต่ครั้งล่าสุด สถานะนั้นปกติสำหรับไคลเอนต์ที่ไม่ใช้งาน และน่ากังวลเฉพาะเมื่อคุณคาดว่าทราฟฟิกควรไหลไปแล้ว ตรวจตัวนับการถ่ายโอนด้วย เพราะมันแยก “ไม่ได้ส่งอะไร” ออกจาก “ลองแล้วแต่ล้มเหลว”

หากตัวนับทั้งสองฝั่งเป็นศูนย์ ปัญหาอยู่เหนือทันเนลขึ้นไป ไม่มีอะไรไปถึงอินเทอร์เฟซเพื่อกระตุ้นอะไร

กระตุ้นทราฟฟิกที่ peer ได้รับอนุญาตให้พาไป

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

ip route get 10.60.9.5
ping -c 3 -W 2 10.60.9.5
wg show wg0 latest-handshakes
wg show wg0 transfer

การสอบถามเส้นทางสำคัญกว่า ping หากระบุอินเทอร์เฟซทางกายภาพ แพ็กเก็ตไม่เคยเข้าทันเนล และแฮนด์เชกว่างคือคำตอบด้านเส้นทาง ไม่ใช่ด้านการเข้ารหัส แก้เส้นทางก่อนดีบัก peer

เปรียบเทียบคู่คีย์และปลายทาง

เมื่อมีการเสนอทราฟฟิกจริง การตรวจสอบถัดไปคือตัวตน คีย์ส่วนตัวโลคอลต้องตรงกับคีย์สาธารณะที่อีกฝั่งอนุญาต คีย์สาธารณะระยะไกลที่กำหนดค่าไว้ต้องระบุ peer ที่ตั้งใจ และคีย์ที่แชร์ล่วงหน้าต้องตรงกันทั้งสองฝั่ง ความต่างเพียงอักขระเดียวในคีย์ base64 ทำให้ peer ดูเหมือนกำหนดค่าแล้วแต่ไม่เคยแลกเปลี่ยนสำเร็จ เปรียบเทียบกับบันทึกการจัดเตรียมแทนการสร้างคีย์ใหม่ เพราะคีย์ใหม่จะทำให้ peer ทุกตัวที่เชื่อคีย์เก่าใช้ไม่ได้

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

เฝ้าดูเส้นทาง UDP ภายนอก

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

ss -lunp | grep 51820
sudo tcpdump -ni eth0 udp port 51820
wg show wg0 endpoints
conntrack -L -p udp | grep 51820

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

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