Android OpenVPN: เพิ่มเส้นทางส่วนตัวโดยไม่ต้องรูทโทรศัพท์
เพิ่มเส้นทางหนึ่งเส้นในโปรไฟล์ที่ Android โหลดจริง แล้วตรวจสอบว่าเซิร์ฟเวอร์อนุญาตหรือไม่ คู่มือสำหรับการแก้ไข การเชื่อมต่อใหม่ และการตรวจสอบสี่ข้อ
คุณต้องมีซับเน็ตส่วนตัวเพิ่มอีกหนึ่งอัน — สมมติว่า 10.60.0.0/24 — ที่โปรไฟล์ยังไม่มีอยู่ในตอนนี้ บนแล็ปท็อปคุณจะเพิ่มเส้นทางแล้วไปต่อ บน Android นั้น VPN เป็นแอป อุปกรณ์ tun เป็นของแอปนั้น และไม่มีตารางเส้นทางให้แก้ไขได้โดยไม่ต้องรูท เส้นทางยังต้องมีอยู่ แต่จะเข้าไปอยู่ในโปรไฟล์ที่ไคลเอนต์โหลด และจะทำงานก็ต่อเมื่ออีกฝั่งยอมรับ นี่คือการแก้ไข การเชื่อมต่อใหม่ ฝั่งเซิร์ฟเวอร์ และการย้อนกลับ
ก่อนแก้ไข: เส้นทางทำอะไรได้และทำอะไรไม่ได้
เส้นทางตอบคำถามข้อเดียว: อินเทอร์เฟซใดควรรับทราฟฟิกไปยังปลายทางนี้ มันไม่ได้ให้สิทธิ์อะไรเลย หากเจ้าของเครือข่ายไม่ได้ตกลงว่าโทรศัพท์เครื่องนี้เข้าถึงซับเน็ตนั้นได้ เส้นทางที่ถูกต้องจะสร้างการกำหนดค่าที่ดูถูกต้องและการทิ้งอย่างเงียบที่เกตเวย์ แล้วคุณจะเสียเวลาหนึ่งชั่วโมงถัดไปแก้ไฟล์ผิด
ขอความตกลงนั้นก่อน เป็นลายลักษณ์อักษรหากเครือข่ายมีเจ้าของ จากนั้นบันทึกว่าคุณไม่ได้ทำอะไร: คุณไม่ได้ให้ที่อยู่แก่โทรศัพท์ภายใน LAN นั้น ไม่ได้เปลี่ยนตัวรับฟังของเซิร์ฟเวอร์ และไม่ได้เลือกไซต์ตามชื่อโฮสต์ สิ่งเหล่านี้คือสี่การเปลี่ยนแปลงที่ต่างกัน และมีเพียงอย่างแรกที่เป็นของคุณ
| The route gives you | The route does not give you |
|---|---|
| A destination prefix associated with the tunnel | Permission to forward at the gateway |
| A path for the phone's own traffic | A return route on the target host |
| A scope for the client's virtual interface | A name in DNS, or HTTPS identity |
แก้ไขโปรไฟล์ที่ไคลเอนต์โหลดจริง
สำหรับไคลเอนต์ที่เข้ากันได้ซึ่งนำเข้าข้อความตัวเลือก OpenVPN ปกติ การเพิ่มคือหนึ่งบรรทัด:
route 10.60.0.0 255.255.255.0เพิ่มลงในเนื้อหาของโปรไฟล์ ใกล้คำสั่งเส้นทางอื่น และคง endpoint ใบรับรอง การจัดการคีย์ และบรรทัดตรวจสอบของผู้ให้บริการไว้เหมือนเดิมทุกประการ อย่าวางตัวอย่างเก่าทั้งหมดเพื่อขอยืมหนึ่งบรรทัด: การบีบอัด พาธไฟล์แบบสัมบูรณ์ และการตั้งค่า cipher ที่ล้าสมัยจะติดมาด้วยและจะทำให้คุณต้องเสียเวลาแก้จุดบกพร่องแยกต่างหาก
ขั้นตอนที่ผู้คนมองข้ามคือความเป็นเจ้าของไฟล์ หากแอปนำเข้าโปรไฟล์ สำเนาที่ใช้คือของแอป และการแก้ไฟล์ต้นฉบับที่ดาวน์โหลดมาไม่เปลี่ยนอะไรเลย ใช้ตัวแก้ไขที่ไคลเอนต์รองรับ หรือนำเข้าไฟล์ที่แก้ไขใหม่ผ่านเส้นทางการอัปเดต และยืนยันชื่อโปรไฟล์ที่ใช้งานอยู่เมื่อมีชื่อคล้ายกันหลายชื่อ บันทึกว่าคุณเปลี่ยนอันไหน
หากโปรไฟล์มี route-nopull อยู่แล้ว จะไม่มีการติดตั้งเส้นทางใดจากเซิร์ฟเวอร์ และทุกคำนำหน้าที่โทรศัพท์ต้องการต้องระบุอย่างชัดเจน นั่นเป็นการออกแบบที่ชอบด้วยกฎหมาย แต่หมายความว่าบรรทัดที่ละไว้จะดูเหมือนการปฏิเสธของเซิร์ฟเวอร์ทุกประการ
เชื่อมต่อใหม่และตรวจสอบบนอุปกรณ์
ตัดการเชื่อมต่อก่อน จากนั้นเชื่อมต่อใหม่กับโปรไฟล์เฉพาะที่คุณแก้ไข แทนที่จะปล่อยให้แอปกู้คืนเซสชันล่าสุด เปิดบันทึกการเชื่อมต่อและยืนยันว่าไคลเอนต์แยกวิเคราะห์บรรทัดใหม่แล้ว คำสั่งเส้นทางที่ส่วนหน้าละเลยเป็นผลลัพธ์ปกติของการแก้สำเนาที่ผิด
ทดสอบปลายทางด้วยที่อยู่ ไม่ใช่ชื่อ การตรวจ TCP ไปยังพอร์ตบริการที่รู้จักให้ข้อมูลมากกว่า ping เพราะโฮสต์จำนวนมากตอบ ICMP ขณะที่พอร์ตบริการถูกกรอง หากที่อยู่ตอบแต่ชื่อไม่ตอบ คุณมีคำถามเรื่องตัวแปลงชื่อ ไม่ใช่เรื่องเส้นทาง และหัวข้อถัดไปไม่ใช่สำหรับคุณ
การตรวจขอบเขตสองข้อก็อยู่ที่นี่เช่นกัน VPN แบบแยกตามแอปหมายความว่าเส้นทางที่อยู่อาจมีอยู่ขณะที่แอปที่คุณใช้ทดสอบอยู่นอกชุดที่รวมไว้ จึงควรทดสอบด้วยแอปที่อยู่ข้างในจริง ๆ และคำนำหน้า IPv4 ไม่ได้บอกอะไรเกี่ยวกับเส้นทาง IPv6 หากบริการเป็น dual-stack ให้เพิ่มเส้นทาง IPv6 ที่เกี่ยวข้อง หรือคาดว่าไคลเอนต์จะเลือกเส้นทางที่คุณไม่ได้ตั้งใจ
ผลลัพธ์เชิงลบข้อหนึ่งควรรู้ไว้แต่เนิ่น ๆ: หากเส้นทาง full-tunnel ครอบ 0.0.0.0/0 อยู่แล้ว คำนำหน้าไม่ได้หายไป และการเพิ่มอีกครั้งไม่เปลี่ยนอะไร การครอบคลุมซ้ำไม่สามารถซ่อมการปฏิเสธฝั่งเซิร์ฟเวอร์หรือการตอบกลับที่หายไปได้
ทำให้เส้นทางสมบูรณ์บนเซิร์ฟเวอร์
สามสิ่งต้องเป็นจริงนอกเหนือจากโทรศัพท์ เกตเวย์ต้องมีเส้นทางไปยังปลายทางและได้รับอนุญาตให้ส่งต่อแหล่งต้นทางของโทรศัพท์ไปทางนั้น ปลายทางต้องยอมรับแหล่งต้นทางนั้นและส่งการตอบกลับผ่านเกตเวย์ มิฉะนั้นการออกแบบต้องมีการแปลอย่างตั้งใจที่ทางออก ตัวเลือก route ในคู่มือ OpenVPN ครอบคลุมคำสั่งฝั่งไคลเอนต์ ส่วนการส่งต่อและการกำหนดเส้นทางย้อนกลับเป็นการตั้งค่าแยกบนเครื่องแยก
หากปลายทางอยู่หลังไคลเอนต์ VPN อื่นแทนที่จะอยู่หลังเกตเวย์โดยตรง เซิร์ฟเวอร์ต้องมี iroute สำหรับซับเน็ตของเพียร์นั้น คำสั่งนั้นเป็นของเซิร์ฟเวอร์และอธิบายว่าไคลเอนต์ใดเป็นเจ้าของคำนำหน้า โทรศัพท์ไม่สามารถให้ได้จากโปรไฟล์ของตัวเอง และการแก้ไขฝั่งไคลเอนต์มากเท่าไรก็ไม่ทดแทนได้
ตรวจสอบเส้นทางย้อนกลับอย่างชัดเจน การตอบกลับที่ออกทางเส้นทางเริ่มต้นแทนที่จะออกทางอุโมงค์ทำให้เกิดอาการกึ่งเปิดแบบคลาสสิก: การเชื่อมต่อถูกสร้างในทิศทางเดียวและไม่มีอะไรกลับมา การแปลแหล่งต้นทางที่เกตเวย์เป็นการแก้ไขที่ชอบด้วยกฎหมายเมื่อปลายทางไม่สามารถกำหนดเส้นทางย้อนกลับได้ แต่มันเป็นการตัดสินใจเชิงนโยบายที่มีผลตามมาในตัวเอง
การย้อนกลับและการยอมรับ
เก็บโปรไฟล์ก่อนหน้าไว้ก่อนแก้ไข หากการเปลี่ยนแปลงทำให้แย่ลง ให้คืนสำเนานั้นผ่านเส้นทางการนำเข้าใหม่เดิม เชื่อมต่อใหม่ และยืนยันว่าพฤติกรรมเดิมกลับมา — นั่นยืนยันว่าคุณเปลี่ยนสิ่งที่คุณคิดว่าเปลี่ยน การย้อนกลับที่ไม่คืนสถานะเดิมหมายความว่าแอปถือสำเนาที่สามที่คุณยังหาไม่พบ
ยอมรับการเปลี่ยนแปลงเมื่อสี่สิ่งคงอยู่ ทดสอบตามลำดับนี้หลังการเชื่อมต่อใหม่: ปลายทางตอบบนพอร์ตบริการของตน ชื่อส่วนตัวแปลงได้หากคาดหวังไว้ HTTPS ยังตรวจสอบชื่อโฮสต์ที่ตั้งใจ และทุกอย่างยังทำงานหลังรีบูตหรือเปลี่ยนจาก Wi-Fi ไปเป็นเครือข่ายมือถือ การตรวจสุดท้ายคือสิ่งที่จับเส้นทางที่มีอยู่เพียงจนกว่า Android จะสร้างอุโมงค์ใหม่
- ยืนยันว่าเจ้าของเครือข่ายอนุญาตปลายทางก่อนแก้ไขสิ่งใด
- ใส่เส้นทางในโปรไฟล์ที่ไคลเอนต์โหลด แล้วนำเข้าใหม่และเชื่อมต่อใหม่
- ตรวจสอบผ่านพอร์ตบริการ ภายในขอบเขตแยกตามแอป สำหรับตระกูลที่อยู่ที่ถูกต้อง
- แก้การส่งต่อ การกำหนดเส้นทางย้อนกลับ และ iroute บนเซิร์ฟเวอร์ ไม่ใช่บนโทรศัพท์
- เก็บสำเนาสำหรับย้อนกลับ และทดสอบใหม่หลังรีบูต