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

คำถามเรื่องสถาปัตยกรรมมาก่อน เพราะบอร์ด 64 บิตอาจรันพื้นที่ผู้ใช้ 32 บิต และแอปให้มาเพียงอย่างใดอย่างหนึ่ง

สองขอบเขตการสนับสนุน ไม่ใช่ตัวติดตั้งสองตัว

อ่านหน้าติดตั้งปัจจุบันของผู้ให้บริการสำหรับแอปที่คุณจะใช้ แล้วเทียบกับบอร์ด: รุ่นของดิสทริบิวชัน สถาปัตยกรรมของแพ็กเกจ และข้อกำหนดด้านเดสก์ท็อปหรือเซสชัน การที่ Pi รองรับการทำงาน 64 บิตไม่ได้บอกว่าพื้นที่ผู้ใช้ใดถูกติดตั้งอยู่ตอนนี้ และตัวจัดการแพ็กเกจตรวจสอบค่านั้น dpkg --print-architecture และ uname -m ตอบคำถามนั้นด้วยบรรทัดละคำสั่ง ถ้ารุ่นหรือสถาปัตยกรรมอยู่นอกชุดที่เอกสารระบุ แอปจะไม่ได้รับการสนับสนุนที่นั่นแม้จะติดตั้งได้

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

สิ่งที่แอปให้และโปรไฟล์ไม่ให้

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

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

WireGuard แบบทำเอง: ขั้นตอนที่สำคัญ

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

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

ตัดสินใจว่า Pi เป็นเกตเวย์ด้วยหรือไม่

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

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

ความเชื่อที่ควรทิ้งคือตัวติดตั้ง Linux และไฟล์ WireGuard แทนการตัดสินใจเดียวกัน ทั้งสองคือรูปแบบการทำงานสองแบบที่มีเจ้าของต่างกัน

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