VPN บน Android แก้ชื่อโฮสต์เต็มได้ แต่แก้ชื่อย่อไม่ได้
โดเมนค้นหาและที่อยู่เซิร์ฟเวอร์ DNS เป็นสองฟิลด์แยกกันใน Android ตัดสินใจว่าอันไหนขาดก่อนเปลี่ยนอุโมงค์หรือข้อมูลรับรอง
คุณพิมพ์filesลงในโปรแกรมจำลองเทอร์มินัลแล้วไม่มีอะไรตอบกลับ คุณพิมพ์files.corp.exampleแล้วเซิร์ฟเวอร์เดิมตอบกลับทันที ข้อมูลรับรอง VPN ไม่ได้เปลี่ยน และเซิร์ฟเวอร์ DNS ส่วนตัวไม่เคยเสีย บน Android ชื่อย่อและชื่อเต็มเดินคนละเส้นทางผ่านตัวแก้ไข และเส้นทางหนึ่งขึ้นอยู่กับการตั้งค่าที่เจ้าของอุโมงค์ต้องจัดหา การตัดสินใจตรงหน้าคุณไม่ใช่จะเปลี่ยนเซิร์ฟเวอร์ DNS ตัวไหน แต่เป็นใครควบคุมเครือข่ายที่แอปใช้จริง
โดเมนค้นหาไม่ใช่ที่อยู่ มันคือรายการส่วนต่อท้ายที่ตัวแก้ไขเติมให้กับป้ายเปล่า ๆ ก่อนยอมแพ้
ส่วนต่อท้ายการค้นหาและเซิร์ฟเวอร์ DNS เป็นฟิลด์แยกกัน
ที่อยู่ของตัวแก้ไขบอก Android ว่าจะถามที่ไหน ส่วนต่อท้ายการค้นหาบอกว่าจะถามอะไรเมื่อคุณระบุเพียงป้ายซ้ายสุด ทั้งสองอยู่บนออบเจ็กต์เครือข่ายเดียวกัน และแต่ละอย่างขาดหายไปได้เอง
ความเป็นอิสระนี้เองอธิบายว่าทำไมชื่อโฮสต์เต็มจึงทำงานได้ ชื่อที่ระบุคุณสมบัติครบไม่ต้องใช้ส่วนต่อท้าย เพราะมันเป็นสตริงที่ส่งไปยังเซิร์ฟเวอร์อยู่แล้ว
Android เปิดเผยการแยกนี้ผ่านLinkProperties รายการเซิร์ฟเวอร์ DNS และรายการค้นหาโดเมนอยู่บนออบเจ็กต์เดียวกัน และรายการหลังมักว่างเปล่าแม้รายการแรกจะเต็ม เครือข่ายที่มีตัวแก้ไขแต่ไม่มีโดเมนคือเครือข่ายที่ไม่เคยใช้ส่วนต่อท้ายเลย ไม่ใช่เซิร์ฟเวอร์ที่ปฏิเสธชื่อย่อ
อ่านเครือข่ายที่ใช้งานจริงก่อนเปลี่ยนอะไร
Wi-Fi เครือข่ายมือถือและอินเทอร์เฟซ VPN เป็นสามเครือข่ายแยกกัน และอุโมงค์กลายเป็นค่าเริ่มต้นทันทีที่ขึ้นมา ดังนั้นส่วนต่อท้ายที่เคยใช้ได้บน Wi-Fi ของออฟฟิศจึงไม่ใช่ส่วนต่อท้ายที่บังคับใช้ขณะอุโมงค์ทำงานโดยอัตโนมัติ ตรวจสอบเครือข่ายที่แอปถูกเลือกจริง ไม่ใช่เครือข่ายที่คุณตั้งค่าไว้เมื่อสัปดาห์ก่อน
เชลล์เทอร์มินัลบนอุปกรณ์เป็นพยานที่ไม่ดีในที่นี้ เพราะresolv.confของมันสะท้อนมุมมองหนึ่งของตัวแก้ไข ไม่ใช่ของทุกแอป
แถบที่อยู่ของเบราว์เซอร์เพิ่มอีกชั้นหนึ่ง คำเปล่า ๆ อาจถูกตีความเป็นคำค้นหา หรือแก้ผ่านนโยบาย DNS ที่เข้ารหัสของเบราว์เซอร์เอง ดังนั้นหน้าที่โหลดใน Chrome จึงไม่ได้พิสูจน์อะไรเกี่ยวกับการค้นหาของระบบ ทดสอบด้วยสิ่งที่ใช้ตัวแก้ไขของแพลตฟอร์มและพิมพ์สิ่งที่ส่งกลับมา จากนั้นรันรูปแบบย่อและรูปแบบเต็มในเซสชันเดียวกัน บนเครือข่ายเดียวกัน แล้วบันทึกว่าอันไหนให้คำตอบ
หากคุณสร้างแอป VPN ให้แนบส่วนต่อท้ายในตัวสร้าง
เมื่อแอปของคุณตั้งค่าอินเทอร์เฟซผ่านVpnService,addSearchDomainนี่คืออินพุตที่รองรับสำหรับเรื่องนี้ มันรับสตริงโดเมนเช่นcorp.example และไม่ใช่วิธีอื่นในการส่งที่อยู่เซิร์ฟเวอร์
การเรียกนี้ผูกส่วนต่อท้ายกับเครือข่ายที่คุณกำลังสร้าง จึงไม่มีค่าตั้งระดับโลกให้พลิกกลับภายหลัง หากแอปฉีกอินเทอร์เฟซและสร้างใหม่เมื่อเชื่อมต่อใหม่ ตัวสร้างใหม่ต้องเพิ่มส่วนต่อท้ายอีกครั้ง ไม่เช่นนั้นเครือข่ายแทนจะขึ้นมาโดยไม่มีมัน
นี่คือจุดที่การนำเข้าโปรไฟล์เดสก์ท็อปจำนวนมากสูญเสียฟิลด์นี้ ตัวส่งออกเขียนโดเมนลงในโมเดลของตัวเอง ฟรอนต์เอนด์ Android แมปเฉพาะตัวเลือกที่รู้จัก และอินเทอร์เฟซที่ได้จึงดูถูกต้องในทุกด้านอื่น โปรไฟล์ที่ทำงานบนแล็ปท็อปแต่ล้มเหลวบนโทรศัพท์มักเป็นช่องว่างของการแมป ไม่ใช่ปัญหาโปรโตคอล
หากคุณเพียงใช้ VPN นี่ไม่ใช่เรื่องที่คุณจะตั้ง
ไม่มีการแก้ไขฝั่งไคลเอนต์ที่เพิ่มส่วนต่อท้าย และไม่มีพร็อพเพอร์ตี้ระดับโลกให้เปลี่ยนเพื่อปลอมแปลง ค่านั้นจัดหาโดยผู้ที่เป็นเจ้าของอุโมงค์ ในโปรไฟล์ของไคลเอนต์ที่จัดการ ในการแมปแยกตามแพลตฟอร์ม หรือผ่านสิ่งที่เซิร์ฟเวอร์ส่งมา บอกว่าคุณอยู่บนแพลตฟอร์มใดและชื่อใดล้มเหลว เพราะฟรอนต์เอนด์เดสก์ท็อปและมือถือแตกต่างกันตรงฟิลด์นี้พอดี
การนำเข้าโปรไฟล์เดสก์ท็อปซ้ำยังคงไม่ได้พิสูจน์อะไรเกี่ยวกับการแมปบนมือถือ
สามเงื่อนไขตัดสินว่าคุณมีข้อบกพร่องหรือข้อจำกัดที่คาดไว้ ข้อแรก องค์กรถือว่าชื่อย่อเป็นชื่อที่รองรับเลยหรือไม่ หรือมันเป็นความสะดวกที่เคยใช้ได้เฉพาะบน Wi-Fi ของออฟฟิศ ข้อสอง การค้นหาที่ล้มเหลวมาจากเบราว์เซอร์ซึ่งอาจข้ามตัวแก้ไขของระบบไปเลยหรือไม่ ข้อสาม ชื่อย่อควรเข้าถึงได้ผ่านอุโมงค์หรือเฉพาะจาก LAN หากคำตอบสุดท้ายคือ LAN เท่านั้น การเพิ่มส่วนต่อท้ายจะสร้างชื่อที่แก้ได้นอกออฟฟิศแล้วจึงไม่ถูกกำหนดเส้นทาง
เมื่อมีส่วนต่อท้ายแล้วแต่ชื่อย่อยังล้มเหลว
หากรายการค้นหาโดเมนแสดงcorp.exampleอยู่แล้ว อย่าโทษส่วนต่อท้าย ตรวจสอบว่าตัวแก้ไขตอบกลับชื่อที่ขยายแล้วหรือไม่ เพราะส่วนต่อท้ายเปลี่ยนเพียงคำถามที่คุณถาม มันไม่เคยทำให้เซิร์ฟเวอร์มีอำนาจเหนือโซนที่ไม่ได้โฮสต์
จากนั้นตรวจสอบเส้นทาง ที่อยู่ที่แก้ได้แต่ถูกอุโมงค์ไม่พาไปจะล้มเหลวตอนเชื่อมต่อ ซึ่งดูเหมือนการค้นหาที่ล้มเหลวในเบราว์เซอร์ที่ยอมแพ้เงียบ ๆ
ใบรับรองสมควรได้รับการกล่าวถึงแยกต่างหาก การตรวจสอบ HTTPS ใช้ชื่อโฮสต์ที่คุณพิมพ์จริง ดังนั้นชื่อย่อที่ขยายถูกต้องยังคงนำเสนอfilesในการจับมือ ใบรับรองที่ออกให้files.corp.exampleจะไม่ใช้ได้กับมัน และข้อผิดพลาดนั้นเป็นพฤติกรรมที่ถูกต้อง ไม่ใช่อาการของปัญหา DNS ที่คุณเริ่มต้น
จะทำอะไรต่อ
ยืนยันการแยกก่อนแตะอะไร ชื่อเต็มแก้ได้ ชื่อย่อไม่ได้ แอปเดียวกัน เซสชันเดียวกัน จากนั้นหาเครือข่ายที่เลือกและอ่านรายการค้นหาโดเมนควบคู่กับรายการตัวแก้ไข อันไหนในสองอันที่ว่างจะบอกคุณว่าใครต้องลงมือ คุณ หากแอปเป็นของคุณ ผู้ให้บริการอุโมงค์ หากไม่ใช่
สุดท้าย ให้เลือกชื่อโฮสต์บริการแบบเต็มในบุ๊กมาร์กและการตั้งค่าไคลเอนต์ทุกที่ที่ความสามารถในการพกพาสำคัญ มันทนต่อการเปลี่ยนเครือข่าย ไม่ขึ้นกับการแมปที่ฟรอนต์เอนด์มือถืออาจไม่ได้ทำ และตรงกับชื่อที่ใบรับรองออกให้