เซิร์ฟเวอร์ VPN บน Pi: เริ่มจากแอปในโทรศัพท์ ไม่ใช่จากสูตร

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

ลำดับที่ประหยัดการสร้างใหม่

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

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

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

แอปในโทรศัพท์ใช้งานอะไรจริง ๆ

รายการไคลเอนต์ที่เผยแพร่อธิบายแอปพลิเคชัน ไม่ใช่บริการ แอป OpenVPN Connect สำหรับ Android คาดหวังเซิร์ฟเวอร์ OpenVPN และไม่ได้ให้ฝั่งเซิร์ฟเวอร์ นอกจากนี้ยังไม่กลายเป็นไคลเอนต์ IPsec หรือ L2TP เมื่อโปรไฟล์ดูคล้ายกัน

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

ตรวจสอบเอกสารปัจจุบันของแอปว่าไฟล์โปรไฟล์รูปแบบใดที่นำเข้า ก่อนผูกมัดกับแพ็กเกจเซิร์ฟเวอร์ ห้านาทีของการอ่านดีกว่าการสร้างใหม่

ข้อตกลงสี่ส่วน

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

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

ข้อมูลรับรองมีหน้าที่แยกกัน

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

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

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

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

การเข้าถึงเป็นสัญญาแยกต่างหาก

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

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

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