วิธีสร้างการทดสอบ WireGuard แบบสองเพียร์ที่พิสูจน์เส้นทางเดียว

อุโมงค์หนึ่งเส้น คู่แอดเดรสหนึ่งคู่ ทรัพยากรที่อนุญาตหนึ่งอย่าง WireGuard พื้นฐานน้อย ๆ ทำให้ทุกการเปลี่ยนแปลง forwarding, NAT หรือ DNS ในภายหลังมองเห็นได้

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

สิ่งที่พื้นฐานพิสูจน์นั้นแคบกว่าที่คนส่วนใหญ่คาด มันพิสูจน์ว่าสองตัวตนตรงกัน ว่า UDP ไปถึงพอร์ตที่รอฟัง และว่าปลายทางที่อนุญาตหนึ่งแห่งพาคำขอไปได้ การส่งต่อ NAT เส้นทาง LAN และ DNS เป็นคุณสมบัติแยกที่ค่อย ๆ เพิ่มทีหลัง ทีละอย่าง

คีย์ แอดเดรส และ endpoint เดียว

สร้างคู่คีย์บนแต่ละระบบและย้ายเฉพาะครึ่งสาธารณะระหว่างกัน wg genkey | tee privatekey | wg pubkey > publickey คือคำสั่งบรรทัดเดียวที่มีเอกสารกำกับ และมันทิ้งคีย์ส่วนตัวไว้ในไฟล์ที่คุณปกป้องได้ภายหลัง เลือกแอดเดรสอุโมงค์จากช่วงที่ไม่ปรากฏในการตั้งค่าอื่นใดที่คุณมี, เช่น 10.99.0.1/24 และ 10.99.0.2/24 จดไว้ว่าแอดเดรสไหนเป็นของเครื่องไหน เพราะทุกการตรวจสอบหลังจากนี้อาศัยการจับคู่นั้น

คีย์ส่วนตัวไม่เคยเดินทาง ถ้าการทดสอบต้องคัดลอกไปอีกฝั่ง แสดงว่าการทดสอบผิดไปแล้ว เมื่อสองระบบอยู่หลัง NAT อย่างน้อยหนึ่งฝั่งต้องมีพอร์ต UDP ที่เข้าถึงได้ ขณะที่อีกฝั่งถือ Endpoint ที่ชี้มาที่มัน และแอดเดรสกับพอร์ตสาธารณะควรอยู่ในบันทึกของคุณ ไม่ใช่ในสมมติฐานของคุณเกี่ยวกับ 51820

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

ฟิลด์ที่เป็นของ wg และฟิลด์ที่ไม่ใช่

ชุดฟิลด์หลักมีน้อย: PrivateKey และ ListenPort ใต้ Interface, PublicKey, AllowedIPs และ Endpoint ใต้ Peer ส่วน Address และ DNS เป็นของ wg-quick ไม่ใช่ตัว wg เอง และความต่างนี้กัดทันทีที่การตั้งค่าเดียวกันย้ายไปเครื่องมืออื่น

[Interface]
PrivateKey = <peer-a-private>
Address = 10.99.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <peer-b-public>
AllowedIPs = 10.99.0.2/32
Endpoint = 203.0.113.10:51820

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

อ่านแฮนด์เชกแทนไอคอน

ยกอินเทอร์เฟซขึ้นผ่านสิ่งที่ถือครองมัน แล้วอ่านสถานะแทนไฟสถานะ wg show พิมพ์แฮนด์เชกล่าสุดต่อเพียร์พร้อมตัวนับไบต์ และแฮนด์เชกภายในไม่กี่นาทีที่ผ่านมาหมายถึงคีย์ endpoint และเส้นทาง UDP ทำงานทั้งหมด ตัวนับที่ขึ้นทางเดียวคือคำตอบในตัวเอง และมันไม่ใช่ความล้มเหลวแบบเดียวกับแฮนด์เชกที่ไม่เคยเกิด

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

พิสูจน์บริการที่อนุญาตหนึ่งอย่าง แล้วจึงกลับทิศ

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

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

เก็บพื้นฐานไว้เป็นข้อมูลอ้างอิง

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

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

บทความที่เกี่ยวข้อง