เซิร์ฟเวอร์ VPN บน Android: root ไม่ทำให้โทรศัพท์เข้าถึงได้
ปัญหาสามข้อแยกกันตัดสินว่าโทรศัพท์ให้บริการไคลเอนต์ VPN ได้หรือไม่: เส้นทางขาเข้า โมเดลสิทธิ์ และการส่งต่อ root แตะเพียงข้อกลางเท่านั้น
root เปลี่ยนว่ากระบวนการได้รับอนุญาตให้ลองดำเนินการเครือข่ายใดบ้าง มันไม่ได้ให้ที่อยู่ที่เข้าถึงได้จากสาธารณะแก่โทรศัพท์ ไม่ได้จองการแมปขาเข้าที่ผู้ให้บริการ และไม่ได้ทำให้เดมอนยังมีชีวิตหลังรีบูต หากคุณกำลังตัดสินว่าโทรศัพท์ Android เป็นเซิร์ฟเวอร์ VPN ได้หรือไม่ ให้แยกคำถามสามข้อ: ไคลเอนต์ที่ตั้งใจไว้เข้าถึงตัวรับฟังได้หรือไม่ การใช้งานเซิร์ฟเวอร์ต้องใช้โมเดลสิทธิ์แบบใด และต้องส่งต่ออะไรเมื่ออุโมงค์ขึ้นแล้ว
ใครต้องเข้าถึงโทรศัพท์ และจากที่ใด
ไคลเอนต์บน LAN เดียวกันที่ได้รับอนุญาตและไคลเอนต์บนข้อมูลมือถือกำลังทดสอบสองเครือข่ายที่ต่างกัน กำหนดสิ่งที่ตั้งใจไว้ก่อน เพราะคำตอบไม่สามารถใช้แทนกันได้ บน Wi-Fi ทราฟฟิกขาเข้าที่ไม่ได้ร้องขอมักต้องมีการแมปที่เราเตอร์ต้นทางและเส้นทางสาธารณะที่ใช้งานได้เลยออกไป บนเครือข่ายเซลลูลาร์ NAT ระดับผู้ให้บริการหมายความว่า IPv4 ขาเข้ามักไม่พร้อมใช้งาน ไม่ว่าโทรศัพท์จะอนุญาตอะไร
ประเด็นสุดท้ายนั้นคือสิ่งที่ root แตะต้องไม่ได้ ไฟร์วอลล์ภายในของโทรศัพท์และ NAT ของผู้ให้บริการเป็นระบบที่ต่างกัน และการเปลี่ยนอย่างแรกไม่มีผลต่ออย่างที่สอง ที่อยู่ส่วนติดต่อส่วนตัว ไอคอนข้อมูลมือถือ หรือซ็อกเก็ตที่กำลังฟัง ไม่ใช่หลักฐานของการเข้าถึงได้ หากเส้นทางของผู้ให้บริการมี IPv6 ที่กำหนดเส้นทางได้ทั่วโลก คุณยังต้องมีนโยบายตัวรับฟังและไฟร์วอลล์ที่ตั้งใจไว้สำหรับมัน การมีที่อยู่ไม่เหมือนกับการยอมรับการเชื่อมต่อ
| Client path | What actually decides reachability |
|---|---|
| Same LAN | The phone's listener and its local firewall |
| Wi-Fi, from the internet | A mapping on the upstream router plus a usable public path beyond it |
| Cellular IPv4 | The carrier's NAT, which the handset does not control |
| Cellular IPv6 | Address, listener and firewall policy together |
การให้บริการและการส่งต่อเป็นความสำเร็จสองอย่างที่ต่างกัน
แฮนด์เชก VPN ที่เสร็จสมบูรณ์พิสูจน์ว่าอุโมงค์มีอยู่จริง มันไม่ได้พิสูจน์ว่าไคลเอนต์เข้าถึง LAN หลังโทรศัพท์ได้ หรือว่าโทรศัพท์ทำหน้าที่เป็นทางออกอินเทอร์เน็ตได้ สิ่งเหล่านี้เป็นการกำหนดค่าที่แยกจากกัน สร้างบนแผนที่อยู่ภายใน เส้นทาง พฤติกรรมการตอบกลับ และนโยบายการส่งต่อที่จำกัดขอบเขตสำหรับงานที่คุณต้องการจริง ๆ
รูปแบบความล้มเหลวคาดเดาได้: แฮนด์เชกสำเร็จ ไคลเอนต์แสดงว่าเชื่อมต่อ และไม่มีอะไรโหลด ก่อนแก้ไขไคลเอนต์ ให้ตัดสินว่าคุณกำลังสร้างบทบาทใดในสองบทบาท การเข้าถึงอุปกรณ์บนเครือข่ายของโทรศัพท์จากระยะไกลและทางออกอินเทอร์เน็ตผ่านอุโมงค์เต็มรูปแบบต้องใช้กฎการส่งต่อที่ต่างกัน และการให้ทั้งสองอย่างเมื่อคุณต้องการหนึ่งอย่างจะขยายการเปิดเผยโดยไม่เพิ่มความสามารถที่คุณขอ
โมเดลสิทธิ์เป็นทางเลือก ไม่ใช่ root หรือไม่มีอะไรเลย
เดมอน OpenVPN แบบดั้งเดิมที่ใช้ TUN ของเคอร์เนลต้องใช้ความสามารถที่สอดคล้องกัน การเข้าถึงโหนดอุปกรณ์ และความร่วมมือจากนโยบายความปลอดภัยของ Android root ไม่ใช่การยกเว้นทั่วไปจาก SELinux กระบวนการที่มีสิทธิ์พิเศษยังคงถูกจำกัดโดยนโยบายแพลตฟอร์ม นั่นคือเหตุผลที่ไบนารีที่ทำงานราบรื่นบนเซิร์ฟเวอร์ Linux อาจล้มเหลวบนโทรศัพท์โดยไม่มีข้อผิดพลาดชัดเจนเกี่ยวกับสิทธิ์
การใช้งานเกตเวย์ในพื้นที่ผู้ใช้อาจมีโมเดลสิทธิ์ที่ต่างออกไปทั้งหมด ดังนั้นข้อกล่าวอ้างทั่วไปที่ว่าเซิร์ฟเวอร์ VPN ทุกตัวบน Android ต้องใช้ root จึงกว้างเกินไป สิ่งที่ root ซื้อให้คุณคือความสามารถในการลองดำเนินการมากขึ้น ไม่ใช่การรับประกันว่าจะได้รับอนุญาตหรือผลลัพธ์จะเข้าถึงได้
การลงทะเบียนบริการ VPN ของ Android เองก็เป็นกลไกแยกอีกอย่าง มันให้ส่วนติดต่อไคลเอนต์ที่จัดการได้พร้อมวงจรชีวิตที่กำหนดไว้แกแอป ไม่ใช่ตัวติดตั้งเซิร์ฟเวอร์ทั่วไป และการเริ่มเดมอนจากเทอร์มินัลไม่ได้ให้การจัดการตลอดเวลา นโยบายต่อแอป หรือเส้นทางการกู้คืนของตัวเอง
หากต้องการจุดออก ให้เปลี่ยนสถาปัตยกรรม
เมื่อเป้าหมายเป็นเพียงทางออกอินเทอร์เน็ตระยะไกลผ่านโทรศัพท์ ไม่ใช่ความเข้ากันได้กับโปรไฟล์ OpenVPN ที่มีอยู่ โหนดทางออกที่รองรับในเครือข่ายซ้อนทับคือการออกแบบที่เหมาะสมกว่า Tailscale จัดทำเอกสาร บทบาทโหนดทางออกสำหรับ Android พร้อมขั้นตอนการลงทะเบียน การอนุญาต และการเลือกไคลเอนต์ของตัวเอง
การแลกเปลี่ยนนี้เป็นจริงและควรพูดให้ชัด: คุณยอมรับโปรโตคอลที่ต่างออกไป โมเดลความเชื่อใจที่ต่างออกไป และการพึ่งพาบัญชีและบริการประสานงานนั้น มันไม่ได้ทำให้ไคลเอนต์ OpenVPN ที่ไม่ถูกแก้ไขเข้าร่วมเครือข่ายซ้อนทับ และไม่ได้ให้ตัวรับฟัง OpenVPN บนที่อยู่สาธารณะแก่คุณ
สิ่งที่การติดตั้งยังต้องการ
ไม่ว่าคุณจะเลือกเส้นทางใด พื้นฐานการดำเนินงานเป็นตัวตัดสินว่าจะอยู่ได้หนึ่งสัปดาห์หรือไม่ เก็บข้อมูลรับรองของเซิร์ฟเวอร์เป็นส่วนตัว ออกเอกลักษณ์ไคลเอนต์ที่แตกต่างกัน และวางแผนการเพิกถอนก่อนที่คุณจะต้องใช้มัน ตัดสินว่าการอัปเดตมาถึงอย่างไร อะไรทำให้บริการทำงานอยู่เบื้องหลัง และมันฟื้นตัวอย่างไรหลังรีบูตหรือการเปลี่ยนเครือข่าย
หลีกเลี่ยงทางลัดที่ดูสะดวก: ไบนารีแบบสแตติกที่ล้าสมัย ชื่อส่วนติดต่อที่ฝังตายตัว และสคริปต์เริ่มต้นที่ล้างนโยบายไฟร์วอลล์ที่มีอยู่ จากนั้นยอมรับผลลัพธ์เฉพาะเมื่อผ่านการทดสอบที่เป็นรูปธรรม: ไคลเอนต์ระยะไกลที่ได้รับอนุญาตเข้าถึงทรัพยากรที่ตั้งใจไว้ จุดหมายที่ต้องห้ามยังคงไม่พร้อมใช้งาน และอุปกรณ์กลับมาเองหลังเหตุการณ์วงจรชีวิตที่รองรับ การเข้าถึง root เป็นส่วนผสมหนึ่งที่เป็นไปได้ในผลลัพธ์นั้น และแทบไม่เคยเป็นตัวชี้ขาด