WireGuard พร้อมสำหรับการผลิตจริงหรือไม่? คำตอบไม่ใช่ที่โปรโตคอล

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

คำถามที่อยู่เบื้องหลังคำถาม

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

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

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

ด่านที่หนึ่ง: เส้นทางต้องรองรับ UDP

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

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

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

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

ด่านที่สอง: ต้องมีใครสักคนเป็นเจ้าของคีย์

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

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

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

ด่านที่สาม: แพ็กเกจต้องมีผู้ดูแล

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

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

ด่านที่สี่: ยอมรับภาระงาน ไม่ใช่การจับมือ

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

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

เก็บหลักฐานไว้ข้างเกณฑ์ รวมถึงสถานะภายในเครื่องที่สร้างมันขึ้นมา ดังนี้

wg show
ss -lunp | grep 51820
ip -4 route get 10.63.0.1

การทดสอบสีเขียวบนเครือข่ายที่เงียบสงบด้วยแล็ปท็อปเครื่องเดียวเป็นการสังเกตเริ่มต้น มันไม่ใช่ข้ออ้างเรื่องความน่าเชื่อถือ และการปฏิบัติต่อมันเช่นนั้นคือทางที่ทำให้ดีไซน์ที่ใช้งานได้กลายเป็นดีไซน์ที่ไว้วางใจ