สปลิตทันเนลของคุณไปถึงแอปแต่ไม่ถึงเซิร์ฟเวอร์ DNS ของแอป
สปลิตทันเนลสามารถกำหนดเส้นทางซับเน็ตของแอปได้และยังคงทิ้งตัวแก้ชื่อที่อยู่ข้าง ๆ ไว้ เพิ่มเส้นทางโฮสต์ แล้วตรวจว่า Windows เลือกเซิร์ฟเวอร์ใดจริง ๆ
การกำหนดเส้นทางซับเน็ตของแอปเป็นส่วนที่ชัดเจนของสปลิตทันเนล และไม่ใช่ทั้งหมดของงาน ตัวแก้ชื่อมักอยู่บนที่อยู่ที่ต่างจากแอปที่มันให้บริการ ดังนั้นทันเนลที่ทำงานได้ก็ยังอาจทิ้งการค้นหาไว้ข้างนอกได้ โปรไฟล์ที่บรรทุก 10.80.0.0/16 และไม่มีอย่างอื่นจะส่งคำถามสำหรับ 10.90.0.53 ออกทางอินเทอร์เฟซภายใน ซึ่งไม่มีโซนส่วนตัวอยู่ เพิ่มเส้นทางไปยังตัวแก้ชื่อ แล้วดูครึ่งหลังของปัญหา: เซิร์ฟเวอร์ใดที่ไคลเอนต์เลือกจริง ๆ
ความเชื่อผิด: เส้นทางเดียวครอบคลุมทั้งบริการ
สปลิตทันเนลคือรายการปลายทางที่ผ่านการเชื่อมต่อ ไม่ใช่คำอธิบายของบริการ ซับเน็ตของแอปและที่อยู่ของตัวแก้ชื่อเป็นสองปลายทาง และโปรไฟล์สามารถบรรทุกอย่างหนึ่งโดยไม่มีอีกอย่างได้ เมื่อเกิดขึ้น แอปเข้าถึงได้ด้วยที่อยู่แต่ชื่อของมันล้มเหลว ซึ่งดูเหมือนความผิดพลาดของ DNS มากกว่าช่องว่างของการกำหนดเส้นทาง
ซับเน็ตรอบตัวแก้ชื่อก็ไม่ได้รับการครอบคลุมโดยอัตโนมัติเช่นกัน เส้นทางโฮสต์ไปยังที่อยู่เดียวเพียงพอสำหรับตัวแก้ชื่อนั้นและไม่เปิดเพื่อนบ้านของมัน นั่นคือจุดของเส้นทางโฮสต์: แคบโดยการออกแบบ และลืมได้ง่ายเมื่อบริการถัดไปปรากฏในซับเน็ตเดียวกัน
ต้องมีสามสิ่งจึงจะทำให้การค้นหาทำงานได้: ไคลเอนต์กำหนดเส้นทางที่อยู่ของตัวแก้ชื่อผ่านทันเนล เกตเวย์ยอมรับและส่งต่อคำขอนั้น และตัวแก้ชื่อยอมรับแหล่งที่มาที่ได้รับ คำตอบก็ต้องกลับมาตามเส้นทางที่ตกลงกันไว้ หากขาดอย่างใดอย่างหนึ่ง อาการจะเหมือนกัน จึงควรเขียนตารางที่อยู่ก่อนแตะการกำหนดค่า
กำหนดว่าที่อยู่ใดที่โปรไฟล์ต้องบรรทุก
ระบุปลายทางตามลำดับ: เครือข่ายของแอป ที่อยู่ของตัวแก้ชื่อ และปลายทางสาธารณะที่สิ้นสุดทันเนลเอง ตัวที่สามต้องไม่ถูกกำหนดเส้นทางเข้าทันเนลเด็ดขาด เพราะการเชื่อมต่อภายนอกต้องมีเส้นทางที่มีอยู่ก่อนทันเนล
| Destination | Coverage this example needs |
|---|---|
| Application network | 10.80.0.0/16 through the VPN |
| Private resolver | 10.90.0.53/32 through the VPN |
| Public VPN endpoint | Normal internet path, outside the tunnel |
รวมทั้ง UDP และ TCP สำหรับ DNS เนื่องจากการใช้งานคาดว่าจะรองรับ TCP ควบคู่กับ UDP และเส้นทาง TCP ที่ถูกบล็อกทำให้เกิดความล้มเหลวแบบช้าและบางส่วนแทนที่จะสะอาด หากโซนส่วนตัวให้บริการผ่าน IPv6 ด้วย ข้อยกเว้นโฮสต์ที่เทียบเท่าจะใช้ที่อยู่และคำนำหน้า IPv6 และเป็นรายการแยกต่างหาก
บันทึกว่าโปรไฟล์ครอบคลุมอะไรอยู่แล้วก่อนเพิ่มสิ่งใด เส้นทางซ้ำไม่เป็นอันตราย แต่เส้นทางที่มีอยู่โดยไม่คาดคิดบอกคุณว่าโปรไฟล์ถูกออกแบบสำหรับแผนที่อยู่ที่ต่างจากที่คุณได้รับ
เพิ่มเส้นทางโฮสต์ผ่านเจ้าของการเชื่อมต่อ
สำหรับโปรไฟล์ Windows ดั้งเดิมที่จัดการในเครื่อง เส้นทางเป็นของการเชื่อมต่อไม่ใช่ตารางกำหนดเส้นทางทั่วโลกของเครื่อง ดูตัวอย่างการเพิ่มก่อน แล้วจึงนำไปใช้ด้วยขอบเขตเดียวกับที่โปรไฟล์ใช้
Add-VpnConnectionRoute -ConnectionName 'Office VPN' -DestinationPrefix '10.90.0.53/32' -WhatIf Get-VpnConnection -Name 'Office VPN' | Select-Object -ExpandProperty Routes
คำสั่งแรกแสดงตัวอย่างการเปลี่ยนแปลงโดยไม่ติดตั้งสิ่งใด และคำสั่งที่สองแสดงรายการเส้นทางที่โปรไฟล์บรรทุกอยู่ตอนนี้ เอกสารอ้างอิง Add-VpnConnectionRouteของ Microsoft อธิบายขอบเขตต่อผู้ใช้และสำหรับผู้ใช้ทั้งหมด โปรไฟล์สำหรับผู้ใช้ทั้งหมดต้องมีพารามิเตอร์ขอบเขตของตัวเอง และคำสั่งต่อผู้ใช้กับโปรไฟล์สำหรับผู้ใช้ทั้งหมดจะล้มเหลวหรือไปลงผิดที่
เมื่อโปรไฟล์ถูกจัดการหรือมาจากไคลเอนต์ของผู้จำหน่าย การเปลี่ยนแปลงเป็นของเจ้าของนั้น การวางเส้นทางระบบถาวรทับบนนโยบายการเชื่อมต่อจะทำงานจนกว่านโยบายจะถูกนำไปใช้ใหม่และเส้นทางหายไป ซึ่งมักเกิดขึ้นระหว่างการโทรขอความช่วยเหลือไม่ใช่ระหว่างการทดสอบ ความล้มเหลวนั้นเงียบ: เส้นทางหายไป ชื่อหยุดแก้ และไม่มีใครเชื่อมโยงสองเหตุการณ์เข้าด้วยกัน ใส่การเปลี่ยนแปลงไว้ในบันทึกของเจ้าของเอง เพื่อให้การนำไปใช้ใหม่ครั้งถัดไปบรรทุกมันไว้แทนที่จะลบมัน
หลังจากนำไปใช้ ให้เชื่อมต่อโปรไฟล์ใหม่แทนการถือว่าเส้นทางมีผลแล้ว การเปลี่ยนแปลงเส้นทางบนการเชื่อมต่อที่ใช้งานอยู่ไม่ได้รับเสมอ และการเชื่อมต่อใหม่ยังสร้างสถานะที่ผู้ใช้ของคุณจะมีจริงอีกด้วย
ตรวจว่าตัวแก้ชื่อใดที่ไคลเอนต์ใช้จริง
เส้นทางควบคุมแพ็กเก็ตที่ส่งถึงตัวแก้ชื่อ มันไม่ได้ตัดสินว่าจะส่งชื่อใดไปที่นั่น และการเลือกนั้นเป็นกลไกแยกต่างหาก ใน Windows กฎเนมสเปซที่มีผลสามารถเลือกตัวแก้ชื่อต่อโดเมน ขณะที่การตั้งค่า DNS ของโปรไฟล์ให้ค่าเริ่มต้น สองชั้นนี้อาจไม่ตรงกันโดยไม่เกิดข้อผิดพลาดใด ๆ จึงเป็นเหตุให้คำถามโดยตรงเป็นเพียงครึ่งหนึ่งของหลักฐาน
Get-DnsClientNrptPolicy Resolve-DnsName app.svc.example -Server 10.90.0.53 -Type A
คำสั่งแรกพิมพ์นโยบายเนมสเปซที่บังคับใช้ และคำสั่งที่สองถามตัวแก้ชื่อส่วนตัวโดยตรงถึงชื่อของแอป คำตอบโดยตรงพิสูจน์ว่าเส้นทางและตัวแก้ชื่อทำงาน มันไม่ได้พิสูจน์ว่าการค้นหาของแอปเองเลือกเซิร์ฟเวอร์นั้น เปรียบเทียบกับการค้นหาปกติของชื่อเดียวกันและกับคำตอบที่แอปได้รับ
คำนึงถึงแคชและ DNS ที่ปลอดภัยระดับเบราว์เซอร์ ซึ่งอาจข้ามตัวแก้ชื่อของระบบไปเลยสำหรับชื่อที่ผู้ใช้พิมพ์ ซัฟฟิกซ์การค้นหาเป็นเบาะแสหลอกอีกอย่าง: มันขยายชื่อสั้นให้เป็นชื่อที่ระบุเต็มรูปแบบ และไม่เกี่ยวข้องกับเซิร์ฟเวอร์ใดที่ตอบ
ปิดท้ายด้วยการเชื่อมต่อใหม่และทำการค้นหาปกติซ้ำ แล้วยืนยันว่าการท่องเว็บปกติยังเป็นไปตามนโยบายที่อนุมัติ การแทนที่ตัวแก้ชื่อส่วนตัวด้วยตัวสาธารณะเพื่อให้ชื่อที่ไม่เกี่ยวข้องแก้ได้ไม่ใช่การแก้ไข และมันย้ายคำถามส่วนตัวไปยังที่ที่มันไม่ควรไปอย่างเงียบ ๆ