แชร์การเชื่อมต่อ Windows อยู่หรือเปล่า? เส้นทาง VPN เปลี่ยนไปข้างใต้
อะแดปเตอร์ที่แชร์เปลี่ยนพีซีให้เป็นเราเตอร์ และทราฟฟิกที่ส่งต่อเดินคนละเส้นทางกับแอปบนโฮสต์ ทดสอบจากไคลเอนต์ ไม่ใช่จากโฮสต์
แล็ปท็อปแชร์ Wi-Fi ของตน โฮสต์ท่องผ่านอุโมงค์ได้โดยไม่มีปัญหา และแท็บเล็ตบนการแชร์นั้นก็ไปไม่ถึงไหน โฮสต์เลิกเป็นเพียงไคลเอนต์ในวินาทีที่เปิดการแชร์ ตอนนี้มันเป็นเราเตอร์ และแพ็กเก็ตที่ส่งต่อต้องเจอกฎอีกชุดหนึ่ง สิ่งที่ทำงานบนโฮสต์ไม่ได้บอกอะไรเกี่ยวกับอุปกรณ์ที่อยู่ข้างหลัง รันการตรวจสอบจากไคลเอนต์ปลายทางลงมา แล้วความแตกต่างนี้จะไม่ใช่เรื่องทฤษฎีอีกต่อไป
ความสำเร็จของโฮสต์ไม่ได้พิสูจน์อะไร
การแชร์การเชื่อมต่อมอบงานสี่อย่างให้เครื่องเดียว การกำหนดแอดเดรส การส่งต่อ การแปล และการกรอง ไคลเอนต์ VPN ที่ปกป้องทราฟฟิกที่สร้างขึ้นในเครื่องอาจถือว่าทราฟฟิกที่ส่งต่ออยู่นอกขอบเขตของตนหรืออาจบล็อกไว้โดยเจตนาในฐานะการรั่วไหล ทั้งสองพฤติกรรมไม่ใช่บั๊ก และทั้งคู่ไม่ได้เขียนไว้บนหน้าจอที่เปิดการแชร์ มีเพียงการทดสอบปลายทางลงมาเท่านั้นที่บอกคุณว่าคุณมีแบบไหน
ไคลเอนต์จำนวนมากส่งต่อเฉพาะทราฟฟิกของโฮสต์และไม่ส่งอย่างอื่น ดังนั้นให้ดูหัวข้อการแชร์ในเอกสารของไคลเอนต์แทนที่จะเชื่อว่าอุโมงค์จะเลือกเส้นทางให้แท็บเล็ต อาการที่มองเห็นคืออุปกรณ์ที่เชื่อมต่อ ได้รับแอดเดรส แล้วล้มเหลวที่คำขอแรก ไคลเอนต์ที่ไม่ยอมส่งต่อยังดูสุขภาพดีสมบูรณ์บนโฮสต์
อะแดปเตอร์ตัวไหนถูกแชร์ ตัวไหนให้บริการไคลเอนต์
บันทึกอะแดปเตอร์ทั้งสองตัว เพราะมันถือแอดเดรสต่างกันและฟิลเตอร์ต่างกัน และการเปลี่ยนบนตัวที่ผิดก็อธิบายผลลัพธ์ที่สับสนได้หลายอย่าง โฮสต์ของการแชร์มักยึดแอดเดรสคงที่ฝั่งปลายทางลงมาและรันบริการ DHCP กับ DNS ขนาดเล็กที่นั่น Windows เก็บการส่งต่อเป็นรายอะแดปเตอร์ไม่ใช่ทั้งระบบ ดังนั้นต้องอ่านสถานะทีละอินเทอร์เฟซ
Get-NetAdapter | Where-Object Status -eq 'Up' | Select-Object Name,InterfaceIndex,LinkSpeed
Get-NetIPAddress -AddressFamily IPv4 | Select-Object InterfaceAlias,IPAddress,PrefixLength
Get-NetIPInterface | Select-Object InterfaceAlias,Forwarding,ConnectionState
Get-NetConnectionProfileถ้าการส่งต่อบนอะแดปเตอร์ที่แชร์แสดงเป็นปิดใช้งาน ก็จะไม่มีอะไรทำงานฝั่งปลายทางลงมาไม่ว่าอุโมงค์จะทำอะไร เปิดใช้เฉพาะบนเครื่องที่นโยบายอนุญาตให้เลือกเส้นทางให้อุปกรณ์อื่น
การส่งต่อ การแปล และการกรอง
แพ็กเก็ตที่ส่งต่อต้องไปถึงอุโมงค์ ถูกแปลเป็นสิ่งที่ปลายทางไกลยอมรับ และกลับมาผ่านการแปลเดียวกัน แต่ละขั้นจากสามขั้นนั้นพังได้ และทุกการพังให้ผลเหมือนกันคือไทม์เอาต์ของเบราว์เซอร์ การดักแพ็กเก็ต การค้นหาเส้นทาง และล็อกจากปลายทางไกลมีค่ามากกว่าการทบทวนกล่องโต้ตอบการแชร์อีกครั้ง ขั้นไหนที่ล้มเหลวคือสิ่งที่บอกว่าต้องเปลี่ยนของใคร
ปลายทางไกลอาจต้องการเส้นทางขากลับสำหรับซับเน็ตที่แชร์ด้วย ซึ่งเป็นช่วงที่เซิร์ฟเวอร์ VPN ไม่เคยเห็น ที่ไคลเอนต์แปล เซิร์ฟเวอร์เห็นเพียงแอดเดรสของอุโมงค์และไม่ต้องมีเส้นทางขากลับ ที่ไม่แปล ผู้ที่เป็นเจ้าของเกตเวย์ต้องเพิ่มเส้นทางนั้นโดยเจตนา และนั่นคือคำขอเปลี่ยนแปลง ไม่ใช่การตั้งค่าไคลเอนต์
ทำการตรวจสอบบนไคลเอนต์ ไม่ใช่บนโฮสต์
รันทุกการตรวจสอบบนไคลเอนต์ที่ล้มเหลว ไม่ใช่บนโฮสต์ที่ทำงานอยู่ เก็บแอดเดรสขาออก คำตอบของตัวแก้ชื่อ และการทดสอบแอปไว้ในเซสชันเดียวกัน เพราะผลที่เก็บห่างกันหนึ่งชั่วโมงไม่ได้บอกอะไรเกี่ยวกับวิธีที่ทั้งสามอย่างรวมกัน
Resolve-DnsName intranet.example.net -Type A
Resolve-DnsName intranet.example.net -Type AAAA
Invoke-RestMethod https://api.ipify.org
Test-NetConnection intranet.example.net -Port 443 -InformationLevel Detailedเปรียบเทียบแอดเดรสขาออกกับของโฮสต์เองแล้วบันทึกว่าตรงกันหรือไม่ คำตอบที่ต่างหมายถึงเส้นทางที่ส่งต่อเลี่ยงอุโมงค์ ซึ่งเป็นคำถามเชิงนโยบายที่มีเจ้าของ ไม่ใช่การแก้ไขเร็ว คำตอบที่ตรงกันควบคู่กับแอปที่ล้มเหลวจะย้ายงานไปที่การแก้ชื่อหรือนโยบายของปลายทางไกล อย่าหยุดที่ผล IPv4 เท่านั้น การแชร์อาจผ่านทุกการตรวจสอบ IPv4 ขณะที่ IPv6 ออกทางอื่น ดังนั้นทำการตรวจชื่อและขาออกซ้ำพร้อมระเบียน AAAA และการทดสอบการเชื่อมต่อแบบละเอียด
บนเครื่องที่มีการจัดการ ให้ยืนยันว่าการแชร์ได้รับอนุญาตตั้งแต่แรก เพราะการเปิดให้อุปกรณ์อื่นเข้าถึงเป็นการตัดสินใจเชิงบริหาร ไม่ใช่สวิตช์ความสะดวก หลังการเปลี่ยนแปลงที่รองรับใด ๆ ให้ทำการตรวจสอบซ้ำเมื่อเชื่อมต่อใหม่และอีกครั้งระหว่างที่เกิดเหตุขัดข้อง การที่โฮสต์เชื่อมต่อใหม่ได้เรียบร้อยไม่ได้คืนเส้นทางที่ส่งต่อซึ่งไคลเอนต์ไม่เคยรองรับ