VPN เชื่อมต่อที่บ้านแต่หมดเวลาบน Wi-Fi ของโรงแรม
แล็ปท็อปเครื่องเดิม บัญชีเดิม เครือข่ายอื่น อ่านรหัสข้อผิดพลาดเป็นขั้นตอน ตรวจสอบชื่อ แล้วดักจับแพ็กเก็ตภายนอกก่อนเปลี่ยนการตั้งค่าใด ๆ
แล็ปท็อปเชื่อมต่อ Wi-Fi ที่บ้าน ไคลเอนต์เชื่อมต่อในสามวินาที และโปรไฟล์เดียวกันล้มเหลวที่โรงแรมหนึ่งชั่วโมงต่อมา ระหว่างนั้นไม่มีการอัปเดตสิ่งใดเลย การไล่ดูเรื่องนี้กับลูกค้าที่นั่งอยู่ตรงหน้าคุณเกี่ยวข้องกับการรู้ว่าข้อผิดพลาดใดเป็นของขั้นตอนใดเป็นหลัก เพราะข้อมูลที่มีประโยชน์อยู่ในรหัสที่ไคลเอนต์พิมพ์ออกมา ไม่ใช่ในข้อเท็จจริงว่ามันล้มเหลว ทำสี่ขั้นตอนด้านล่างตามลำดับ แล้วคุณจะรู้ว่าชื่อ แพ็กเก็ต พอร์ต หรือนโยบายเป็นสิ่งที่ปฏิเสธคุณ
อ่านรหัสข้อผิดพลาดเป็นขั้นตอน ไม่ใช่คำตัดสิน
ไคลเอนต์ไปถึงหมุดหมายสามจุดแยกกันก่อนที่อุโมงค์จะเกิดขึ้น มันแก้ชื่อเซิร์ฟเวอร์ ได้รับคำตอบจากบางสิ่งบนเครือข่าย และเจรจาความเชื่อมโยงด้านความปลอดภัย แต่ละหมุดหมายมีข้อความล้มเหลวของตัวเอง และโดยเฉพาะ Windows นั้นใจกว้างกับรหัสที่แตกต่างกันเมื่อคุณรู้ว่ารหัสเหล่านั้นเป็นของขั้นตอนใด
| What the client says | Stage that failed | First thing to run |
|---|---|---|
| 868, name did not resolve | DNS, before any packet leaves for the server | Resolve-DnsName vpn.example.net |
| 721 or 806, remote computer did not respond | Outer protocol filtered, typically GRE or UDP | A capture on the local interface |
| 809, server not responding | A device in the path is dropping the outer flow | The same capture, from a second network |
| 789, security layer error | The security exchange started and was rejected | Certificate and proposal settings on both ends |
สองในรหัสเหล่านั้นหมายความว่าเครือข่ายไม่ได้ผิด 789 หมายถึงแพ็กเก็ตกำลังไหลและปลายทั้งสองไม่ตกลงเรื่องการเข้ารหัส ซึ่งเป็นปัญหาการกำหนดค่าที่คุณแก้ได้ที่บ้าน 868 หมายถึงไม่มีแพ็กเก็ตใดจำเป็นต้องออกไปเลย การออกแบบอุโมงค์จึงไม่เกี่ยวข้องจนกว่าชื่อจะถูกแก้ การจัดรหัสให้ถูกขั้นตอนประหยัดเวลามากกว่าการดักจับใด ๆ เพราะมันบอกคุณว่าจะข้ามขั้นตอนใดในสามขั้นตอนถัดไป
จงระวังอย่างเหมาะสมถ้าไคลเอนต์ไม่ใช่ Windows ไคลเอนต์ของบุคคลที่สามรวบส่วนใหญ่ของสิ่งนี้เป็น "เชื่อมต่อล้มเหลว" นั่นคือเหตุผลที่สองขั้นตอนถัดไปไม่พึ่งข้อความเลย
ตรวจสอบชื่อก่อนโทษอุโมงค์
เครือข่ายโรงแรมและสนามบินดัก DNS ตลอดเวลา และตัวแก้ชื่อที่ตอบด้วยที่อยู่พอร์ทัลสร้างความล้มเหลวที่ดูเหมือนเซิร์ฟเวอร์ตายอย่างแม่นยำ เปรียบเทียบสิ่งที่ตัวแก้ชื่อในเครื่องพูดกับสิ่งที่ตัวแก้ชื่อสาธารณะพูด:
Resolve-DnsName vpn.example.net -Type A
nslookup vpn.example.net 1.1.1.1
ipconfig /all | findstr /i "DNS Servers"ถ้าคำตอบทั้งสองต่างกัน คุณกำลังถูกเปลี่ยนเส้นทาง และการวินิจฉัยที่เหลือก็ไร้ประโยชน์จนกว่าจะแก้เรื่องนั้นได้ ที่อยู่พอร์ทัลโดยเฉพาะจะยอมรับการเชื่อมต่อ TCP อย่างยินดีแล้วหยุดชะงัก นั่นคือเหตุผลที่มันอาจดูเหมือนไฟร์วอลล์บล็อกเมื่อคุณทดสอบด้วยเบราว์เซอร์
ตอนนี้ยืนยันว่าที่อยู่ที่คุณต้องการไปถึงคือที่อยู่ที่ถูกใช้จริง ไคลเอนต์บางตัวแคชการแก้ชื่อครั้งก่อนไว้ตลอดอายุของโปรไฟล์ ดังนั้นการเชื่อมต่อใหม่หลังเปลี่ยน DNS จึงยังไปที่ที่อยู่เก่า ปิดไคลเอนต์ให้สนิทก่อนทดสอบใหม่ แทนที่จะกดตัดการเชื่อมต่อแล้วเชื่อมต่อในหน้าต่างเดิม
หาว่าแพ็กเก็ตภายนอกใดหายไป
อุโมงค์มีการไหลภายนอกที่เป็นของเส้นทางระหว่างคุณกับเซิร์ฟเวอร์ทั้งหมด และการไหลนั้นคือสิ่งที่กล่องกลางจัดประเภทและทิ้ง ดักจับมันที่ไคลเอนต์ แล้วเปรียบเทียบเครือข่ายที่ทำงานได้กับเครือข่ายที่ล้มเหลว บน Windows การดักจับในตัวก็เพียงพอสำหรับการดูครั้งแรก:
pktmon filter remove
pktmon filter add -p 500 -t UDP
pktmon start --capture --pkt-size 128
pktmon stop
pktmon etl2txt PktMon.etlสิ่งที่คุณอยากเห็นคือแพ็กเก็ตของคุณออกไปหรือไม่ และมีอะไรกลับมาหรือไม่ แพ็กเก็ตออกไปโดยไม่มีอะไรกลับมาหมายความว่าเส้นทางหรือปลายทางไกลทิ้งมัน ไม่มีอะไรออกไปเลยหมายความว่าไคลเอนต์ไม่เคยไปถึงการส่ง ซึ่งชี้กลับไปที่การแก้ชื่อหรือนโยบายไฟร์วอลล์ในเครื่อง
ทำแบบทดสอบเดิมซ้ำบนฮอตสปอตมือถือ นี่คือการเปรียบเทียบที่ให้ข้อมูลมากที่สุดเท่าที่คุณมี เพราะมันเอาทุกกล่องในโรงแรมออกจากเส้นทางขณะที่แล็ปท็อป ไคลเอนต์ และข้อมูลรับรองยังเหมือนเดิม ถ้าอุโมงค์ขึ้นบนฮอตสปอต ให้เลิกดูเซิร์ฟเวอร์ ถ้ามันล้มเหลวที่นั่นด้วย คุณมีปัญหาของไคลเอนต์หรือบัญชีที่เครือข่ายไม่เคยเป็นสาเหตุ
เปลี่ยนทรานสปอร์ตหนึ่งอย่างแล้วทดสอบใหม่
เมื่อคุณรู้ว่าการไหลภายนอกถูกทิ้ง คำถามเชิงปฏิบัติคือเครือข่ายอนุญาตการไหลใด เครือข่ายที่จำกัดส่วนใหญ่อนุญาต TCP 443 ขาออกเพราะไม่อย่างนั้นพวกมันทำงานไม่ได้ ดังนั้นการย้ายตัวรับฟังไปที่นั่นจึงเป็นคำตอบปกติ บน OpenVPN นี่คือสวิตช์ฝั่งไคลเอนต์จนกว่าเซิร์ฟเวอร์จะถูกเปลี่ยน:
openvpn --config corp.ovpn --proto tcp-client --remote vpn.example.net 443 --verb 4ไคลเอนต์ IPsec มีสวิตช์เทียบเท่าในแผงการตั้งค่าของตัวเอง โดยปกติอธิบายว่า IPsec บน TCP หรือการผ่าน NAT การเปลี่ยนมันก็เป็นการวินิจฉัยเช่นกัน ถ้าอุโมงค์ขึ้นบน TCP และตายบน UDP คุณได้พิสูจน์ว่าเครือข่ายกรอง UDP และคุณยังพบการตั้งค่าที่จะต้องใช้ทุกครั้งที่ไปสถานที่นั้น
ต้านทานการล่อใจที่จะปิดคุณสมบัติของเราเตอร์ในการลองครั้งแรก การปิดการตรวจสอบสถานะหรือการป้องกันน้ำท่วมบนเครือข่ายโรงแรมนั้นไม่มีให้คุณอยู่แล้ว และบนอุปกรณ์ของคุณเองมันแลกการป้องกันจริงกับแล็ปท็อปหนึ่งเครื่อง บันทึกว่าการตั้งค่าใดเปลี่ยนผลลัพธ์ แล้วใส่กลับและหาทรานสปอร์ตที่เครือข่ายอนุญาตอยู่แล้ว
ตรวจสอบโปรไฟล์เดียวกันบนเครือข่ายที่สอง
ก่อนปิดตั๋ว พิสูจน์ว่าการเปลี่ยนแปลงอยู่รอดหลังออกจากอาคาร เชื่อมต่อใหม่บนเครือข่ายเดิมด้วยการตั้งค่าเดิม ดักจับสามสิบวินาทีแรก และยืนยันว่าไคลเอนต์ไปถึงสถานะเดียวกับที่ไปถึงบนฮอตสปอต:
pktmon filter add -p 443 -t TCP
pktmon start --capture
Get-VpnConnection -Name "Corp" | Select-Object ConnectionStatus, TunnelType, ServerAddressความแตกต่างที่คำสั่งสุดท้ายเปิดเผยนั้นคุ้มค่าที่จะเก็บไว้: โปรไฟล์อาจรายงานอุโมงค์ที่เชื่อมต่ออยู่ขณะที่การกำหนดเส้นทางภายในผิด และนั่นสร้าง "VPN เปิดอยู่แต่ไม่มีอะไรทำงาน" ซึ่งเป็นบทความอื่น ถ้าประเภทอุโมงค์เปลี่ยนหลังการแก้ไขของคุณ โปรไฟล์ก็ไม่ใช่ตัวที่คุณทดสอบ
จากนั้นเขียนสิ่งที่พบในที่ที่คนถัดไปจะดู "โปรไฟล์องค์กรต้องใช้ TCP 443 ที่ไซต์นี้ UDP 500 ถูกกรองโดยโรงแรม" เป็นประโยคที่เพื่อนร่วมงานลงมือทำได้ "VPN ไม่เสถียรในโรงแรม" ไม่ใช่ และมันรับประกันว่าชั่วโมงเดิมจะถูกใช้ไปอีกในเดือนหน้า