WireGuard ใช้ได้บนอินเทอร์เน็ตมือถือ แต่ใช้ไม่ได้บน Wi-Fi เดียวกัน
คำขอจากภายใน LAN ไปยังที่อยู่สาธารณะของเราเตอร์เดินคนละเส้นทางกับคำขอที่มาจากอินเทอร์เน็ตมือถือ ทดสอบจากภายนอกก่อน แล้วจึงเลือกเส้นทางภายใน
อุโมงค์ขึ้นได้บนอินเทอร์เน็ตมือถือ แต่พออยู่ที่บ้านกลับค้างอยู่ที่สถานะกำลังเชื่อมต่อ ทั้งที่เป็นโปรไฟล์เดิม คีย์พีร์เดิม และไม่มีการเปลี่ยนการตั้งค่าใด ๆ ในระหว่างนั้น ความต่างอยู่ที่เส้นทาง คำขอจากภายใน LAN ไปยังที่อยู่สาธารณะของเราเตอร์ไม่ใช่การเดินทางเดียวกับคำขอที่มาจากอินเทอร์เน็ต เกตเวย์ตามบ้านส่วนใหญ่ไม่ทำงานเส้นทางย้อนกลับ หรือทำเฉพาะบางโปรโตคอลเท่านั้น ทำให้อาการดูเหมือนคีย์เสียทั้งที่ไม่มีอะไรเปลี่ยนในคีย์เลย ก่อนจะแตะคีย์ การส่งต่อพอร์ต หรือโปรไฟล์ไคลเอนต์ ให้ระบุก่อนว่าเส้นทางใดล้มเหลว
ที่อยู่เดียว สองเส้นทางที่ต่างกัน
จากภายนอก แพ็กเก็ตไปถึงที่อยู่สาธารณะของเราเตอร์ แล้วกฎส่งต่อพอร์ตก็ส่งต่อไปยังตัวรับฟัง WireGuard บนโฮสต์ภายใน จากภายใน ไคลเอนต์เรียกไปยังที่อยู่สาธารณะเดียวกัน แพ็กเก็ตจึงออกจากไคลเอนต์ไปถึงเราเตอร์ และต้องถูกหันกลับเข้าสู่ LAN จุดหันกลับนี้เองที่สองเส้นทางแยกจากกัน เพราะเราเตอร์ต้องแปลงทราฟฟิกที่ออกจากอินเทอร์เฟซหนึ่งแล้วกลับเข้าอินเทอร์เฟซเดิม การทำงานจำนวนมากทิ้งทราฟฟิกนี้แทนที่จะแปลง แล้วไคลเอนต์ก็รอแฮนด์เชกที่ไม่เคยถูกส่งออกไป
พฤติกรรมนี้มักเรียกว่า NAT ลูปแบ็กหรือแฮร์พินนิง และเป็นเรื่องของเราเตอร์ไม่ใช่ของ WireGuard โดยRFC 4787 ระบุกรณีการแปลงที่เกตเวย์อาจรองรับหรือไม่รองรับไว้ WireGuard เองไม่มีความเห็นเรื่องเส้นทาง เพราะเห็นเฉพาะแพ็กเก็ตที่มาถึงอินเทอร์เฟซของตน เมื่อเราเตอร์ทิ้งทราฟฟิก เดมอนจะไม่ได้รับอะไร ไคลเอนต์รายงานว่าแฮนด์เชกหมดเวลา และล็อกของเซิร์ฟเวอร์ยังว่าง ล็อกที่ว่างจึงเป็นเบาะแสว่าแพ็กเก็ตหยุดอยู่ที่ใด ไม่ใช่หลักฐานว่าเซิร์ฟเวอร์ล่ม นี่คือเหตุผลที่ติดตั้งใหม่แล้วก็ไม่เปลี่ยนอะไร
ทางกลับกันก็สำคัญ ล็อกเซิร์ฟเวอร์ที่แสดงความพยายามแฮนด์เชกจากที่อยู่ใน LAN พิสูจน์ว่าแพ็กเก็ตมาถึงและเส้นทางปกติ ซึ่งย้ายการตรวจสอบไปที่คีย์และที่อยู่ที่อนุญาต อ่านล็อกตามสิ่งที่มันพิสูจน์ ไม่ใช่ตามสิ่งที่คุณอยากเห็น
ทำให้เกิดซ้ำก่อนจะแก้อะไร
ทดสอบจากเครือข่ายภายนอกที่ได้รับอนุญาตด้วยอุปกรณ์เดิมและโปรไฟล์เดิม แล้วทดสอบซ้ำภายใน LAN โดยไม่แก้อะไร แฮนด์เชกที่สำเร็จจากภายนอกและไคลเอนต์ที่ไม่ยอมออกจากอุปกรณ์จากภายในทำให้เกิดสภาวะเดิมขึ้นจริงแทนการเดา ทั้งสองครั้งต้องใช้โปรไฟล์เดียวกัน ไม่อย่างนั้นการเปรียบเทียบก็ไม่พิสูจน์อะไร
จากนั้นดูว่าชื่อเอนด์พอยต์แปลงเป็นที่อยู่ใดสำหรับอุปกรณ์นี้ สามคำสั่งต่อไปนี้ยังแสดงว่าไคลเอนต์เรียกไปยังที่อยู่ใดจริง ๆ ดังนี้
wg show wg0 endpoints
dig +short vpn.example.net A
resolvectl query vpn.example.netคำสั่งแรกบอกว่าอินเทอร์เฟซกำลังใช้เอนด์พอยต์ใดอยู่ คำสั่งอีกสองคำสั่งแสดงว่าชื่อแปลงเป็นอะไรบนเครื่องนี้ ไคลเอนต์ที่เรียกที่อยู่สาธารณะขณะอยู่ในเครือข่ายเดียวกับเซิร์ฟเวอร์กำลังใช้เส้นทางแฮร์พิน ไคลเอนต์ที่เรียกที่อยู่ใน LAN ไม่ได้ทำเช่นนั้น และความล้มเหลวตรงนั้นเป็นเรื่องของการตรวจสอบอีกแบบ ข้อแตกต่างนี้ตัดสินว่าหัวข้อถัดไปใช้ได้หรือไม่
วิธีที่รองรับในการเข้าถึงเซิร์ฟเวอร์ที่อยู่ใกล้
การจัดวางที่สะอาดที่สุดคือคำตอบแบบสปลิตฮอไรซัน ชื่อสาธารณะแปลงเป็นที่อยู่สาธารณะสำหรับอินเทอร์เน็ต และเป็นที่อยู่ใน LAN ของเซิร์ฟเวอร์สำหรับไคลเอนต์ภายใน โปรไฟล์เก็บชื่อเอนด์พอยต์ไว้ชื่อเดียวและตัวแปลงชื่อเป็นผู้เลือกเส้นทาง ซึ่งต้องควบคุมคำตอบ DNS ภายใน ซึ่งเราเตอร์ตามบ้านมักมีให้และองค์กรจัดเตรียมได้อย่างตั้งใจ หากไม่มีการควบคุมนั้น ทางเลือกที่เหลือคือฟีเจอร์ของเราเตอร์หรือโปรไฟล์ที่สอง
ฟีเจอร์ของเราเตอร์คือการสะท้อน เกตเวย์แปลงทราฟฟิกจากภายในไปภายนอกแล้วส่งกลับเข้ามาข้างใน ที่ใดใช้ได้ก็ไม่ต้องแก้ไคลเอนต์ ที่ใดใช้ไม่ได้ก็ไม่มีตั้งค่าไคลเอนต์ใดช่วยได้ ทดสอบด้วยการดูล็อกเซิร์ฟเวอร์ระหว่างการลองจากภายใน ไม่ใช่ด้วยการอ่านรายการฟีเจอร์ของเราเตอร์
การแก้โปรไฟล์ให้เป็นที่อยู่ส่วนตัวเป็นการวินิจฉัย ไม่ใช่การออกแบบ มันพิสูจน์ว่าเซิร์ฟเวอร์ตอบใน LAN และมันทำให้โปรไฟล์เดียวกันพังทันทีที่แล็ปท็อปออกจากบ้าน
| Approach | What it depends on | Where it fails |
|---|---|---|
| Split-horizon name | Control of the internal DNS answer | Clients that resolve through a server outside the zone |
| Router reflection | Gateway support for hairpin translation | Routers that drop the flow silently |
| Private address in the profile | Nothing beyond the LAN | Every network except the one at home |
ทำให้โปรไฟล์ยังใช้ได้เมื่ออยู่ไกลบ้าน
ไม่ว่าจะเลือกเส้นทางใด อย่าแตะการตรวจสอบตัวตน ที่อยู่เอนด์พอยต์ไม่ใช่ตัวตนของพีร์ และการเปลี่ยนที่อยู่ไม่เคยเป็นเหตุผลให้ยอมรับกุญแจสาธารณะที่ไม่เกี่ยวข้องซึ่งบังเอิญตอบกลับ WireGuard ยืนยันด้วยกุญแจ โฮสต์ที่ผิดจึงทำให้แฮนด์เชกล้มเหลว ไม่ใช่ให้สิทธิ์เข้าถึงสิ่งที่ไม่คาดคิด
หากที่อยู่สาธารณะเปลี่ยน DNS แบบไดนามิกคือสิ่งที่ทำให้ชื่อยังมีประโยชน์ และพฤติกรรมการรีเฟรชของไคลเอนต์เป็นตัวกำหนดว่าเปลี่ยนแล้วมีผลเร็วแค่ไหน ทดสอบจากภายนอกหลังการเปลี่ยนที่อยู่ เพราะกรณีใน LAN ยืนยันไม่ได้ ระวังตัวแปลงชื่อที่ยังแคชคำตอบเก่าไว้เกินอายุของเรกคอร์ด ชื่อที่ยังชี้ไปที่อยู่เดิมดูเหมือนเซิร์ฟเวอร์ที่ล่มทุกประการ
จดไว้ว่าโปรไฟล์ใช้ชื่อใดและชื่อนั้นแปลงเป็นอะไรในแต่ละด้านของเส้นแบ่ง โปรไฟล์ที่ขึ้นกับฟีเจอร์ของเราเตอร์ที่ไม่มีใครบันทึกไว้คือสายสนับสนุนที่จะมาถึงเมื่อมีการอัปเดตเฟิร์มแวร์ครั้งถัดไป บันทึกนั้นยังบอกคนถัดไปด้วยว่าความล้มเหลวภายในเป็นกรณีแฮร์พินที่รู้จักดีหรือเป็นเรื่องใหม่