อ่านไฟล์ตั้งค่า WireGuard ทีละบรรทัด ตั้งแต่ Interface ถึง Peer

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

คีย์ interface อธิบายเครื่องนี้

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

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

อย่างอื่นใน [Interface] บล็อกที่มีไคลเอนต์จริงมักถูกเพิ่มโดย wg-quick: DNS, MTU, Table และบรรทัดฮุก สิ่งเหล่านี้ไม่ใช่ฟิลด์ของโปรโตคอล และ wg การตั้งค่าแบบเปล่าเปลือยก็เพิกเฉยต่อมันทั้งหมด

แต่ละรายการ peer อธิบายอีกฝั่งหนึ่ง

[Peer] บล็อกคือฝ่ายปลายไกล PublicKey คือคีย์ที่ได้มาจากฝ่ายนั้น ไม่ใช่คีย์ส่วนตัวของฝ่ายนั้นเลย และ PresharedKey คือความลับเพิ่มเติมแบบเลือกได้ที่ทั้งสองฝั่งต้องเก็บให้เหมือนกัน Endpoint คือที่ที่จะส่งไป และ PersistentKeepalive ขอให้โฮสต์นี้ส่งแพ็กเก็ตหลังช่วงเวลาเมื่อไม่มีอย่างอื่นไหลออก

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

AllowedIPs คือการกำหนดเส้นทาง ไม่ใช่รายการอนุญาต

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

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

wg-quick เพิ่มอะไรไว้รอบโปรโตคอล

wg-quick อ่านไฟล์เดียวกันและทำขั้นตอนเครือข่ายที่โปรโตคอลปล่อยให้ระบบปฏิบัติการ มันกำหนดที่อยู่ interface เพิ่มเส้นทางที่ได้มาจาก AllowedIPs เขียนการตั้งค่าตัวแปลงชื่อ และรันคำสั่งฮุกตามลำดับ

ชั้นนั้นอธิบายความไม่สมมาตรแบบคลาสสิก ไฟล์ที่มี 0.0.0.0/0 และบรรทัด DNS ให้ไคลเอนต์มีเส้นทางเริ่มต้นและตัวแปลงชื่อ และไม่ได้ทำอะไรเลยกับกฎการส่งต่อหรือ NAT ของเซิร์ฟเวอร์ สิ่งเหล่านั้นเป็นของการตั้งค่าเซิร์ฟเวอร์เอง และไม่มีไฟล์ไคลเอนต์ใดให้ได้

ให้ไฟล์มีเจ้าของคนเดียว การแก้ด้วยมือขณะที่ SaveConfig เปิดอยู่หมายความว่า การแก้ไขของคุณจะหายไปครั้งถัดไปที่ interface ลดลง และ interface จะไม่บอกคุณว่าเกิดขึ้น

ตรวจสอบสถานะที่ใช้จริง ไม่ใช่ไฟล์

ไฟล์คือความตั้งใจ สถานะที่ใช้จริงคือสิ่งที่เคอร์เนลถืออยู่ และทั้งสองแยกจากกันทุกครั้งที่ตัวช่วย drop-in หรือฮุกแก้ไขอะไรหลังเปิดใช้งาน

อ่านสถานะสดและการกำหนดที่อยู่ด้วยกัน แล้วเปรียบเทียบทั้งสองกับสิ่งที่คุณเขียน:

sudo wg show
ip -4 addr show dev wg0
ip -4 route show dev wg0
grep -v "^#" /etc/wireguard/wg0.conf

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