กฎ VPN เดียวของ Android ไม่ได้ปิดกั้นเซิร์ฟเวอร์ SSH ที่โฮสต์

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

กฎ VPN เดียวจำกัดอะไรจริง ๆ

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

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

ตัวรับฟังคือปลายทาง ไม่ใช่ส่วนหนึ่งของอุโมงค์

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

กฎการผูกคือการตั้งค่า SSH ธรรมดา: ที่อยู่และพอร์ตที่รอรับ และใครจะยืนยันตัวตนได้ บน Android การตั้งค่าเหล่านั้นอยู่ในคอนฟิกของแอปเอง และเจ้าของโปรเซสของแอปอาจไม่ได้รับอนุญาตให้ใช้พอร์ตพิเศษ นิสัยบนเดสก์ท็อปที่จะผูกพอร์ต 22 ในฐานะ root จึงไม่ย้ายมาโดยไม่เปลี่ยนแปลง

ListenAddress 10.90.0.4
Port 2222
AllowUsers alice

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

เส้นทางตอบกลับคือจุดที่มักพัง

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

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

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

การข้าม VPN ไม่ได้ซ่อมบริการขาเข้า

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

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

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

วินิจฉัยทีละทิศทาง

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

adb shell ip -br addr
adb shell ip route get 10.90.0.9
nc -vz 10.90.0.4 2222

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

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