จะป้องกันความล่าช้าที่เกี่ยวข้องกับบันทึก IPv6 AAAA ได้อย่างไร?

เซิร์ฟเวอร์ Windows ของเรากำลังลงทะเบียนAAAAบันทึกIPv6 กับเซิร์ฟเวอร์ Windows DNS ของเรา อย่างไรก็ตามเราไม่ได้เปิดใช้งานการกำหนดเส้นทาง IPv6 ในเครือข่ายของเราดังนั้นสิ่งนี้มักทำให้เกิดพฤติกรรมการหยุดชะงัก

Microsoft RDP เป็นผู้กระทำความผิดที่เลวร้ายที่สุด เมื่อเชื่อมต่อกับเซิร์ฟเวอร์ที่มีการAAAAบันทึกใน DNS ไคลเอ็นต์เดสก์ท็อประยะไกลจะลองใช้ IPv6 ก่อนและจะไม่ถอยกลับไปเป็น IPv4 จนกว่าการเชื่อมต่อจะหมดเวลา ผู้ใช้ระดับสูงสามารถหลีกเลี่ยงปัญหานี้ได้โดยการเชื่อมต่อกับที่อยู่ IP โดยตรง การแก้ไขที่อยู่ IPv4 ด้วยping -4 hostname.fooจะทำงานได้ทันทีเสมอ

ฉันจะทำอย่างไรเพื่อหลีกเลี่ยงความล่าช้านี้

• ปิดใช้งาน IPv6 บนไคลเอ็นต์หรือไม่
  • ไม่ Microsoft บอกว่าIPv6 เป็นส่วนที่บังคับของระบบปฏิบัติการ Windows
  • มีลูกค้ามากเกินไปที่จะตรวจสอบว่ามีการตั้งค่าทุกที่อย่างสม่ำเสมอ
  • จะทำให้เกิดปัญหามากขึ้นในภายหลังเมื่อเราใช้งาน IPv6 ในที่สุด
• ปิดใช้งาน IPv6 บนเซิร์ฟเวอร์หรือไม่
  • ไม่ Microsoft บอกว่าIPv6 เป็นส่วนที่บังคับของระบบปฏิบัติการ Windows
  • ต้องการแฮ็ครีจิสทรีที่ไม่สะดวกเพื่อปิดการใช้งานสแต็ก IPv6 ทั้งหมด
  • การตั้งค่านี้ถูกต้องในเซิร์ฟเวอร์ทั้งหมดไม่สะดวก
  • จะทำให้เกิดปัญหามากขึ้นในภายหลังเมื่อเราใช้งาน IPv6 ในที่สุด
• มาส์กระเบียน IPv6 บนตัวเรียกใช้ DNS ซ้ำ
  • ไม่เรากำลังใช้ NLNet Unbound และไม่รองรับสิ่งนั้น
• ป้องกันการลงทะเบียนระเบียน IPv6 AAAA บนเซิร์ฟเวอร์ Microsoft DNS หรือไม่
  • ฉันไม่คิดว่ามันจะเป็นไปได้

ณ จุดนี้ฉันกำลังพิจารณาที่จะเขียนสคริปต์ที่ชำระล้างระเบียน AAAA ทั้งหมดจากโซน DNS ของเรา กรุณาช่วยฉันหาวิธีที่ดีกว่า

อัปเดต:การแก้ไข DNS ไม่ใช่ปัญหา @joeqwerty ชี้ให้เห็นในคำตอบของเขาระเบียน DNS จะถูกส่งกลับทันที ทั้งบันทึกAและAAAAใช้งานได้ทันที ปัญหาคือว่าลูกค้าบางราย ( mstsc.exe) จะพยายามเชื่อมต่อผ่าน IPv6 โดยเฉพาะอย่างยิ่งและใช้เวลาสักครู่เพื่อถอยกลับไปเป็น IPv4

ดูเหมือนว่าปัญหาการกำหนดเส้นทาง pingคำสั่งผลิตข้อผิดพลาด "ความล้มเหลวทั่วไป" เนื่องจากที่อยู่ปลายทางเป็น unroutable

C:\Windows\system32>ping myhost.mydomain
Pinging myhost.mydomain [2002:1234:1234::1234:1234] with 32 bytes of data:
General failure.
General failure.
General failure.
General failure.
Ping statistics for 2002:1234:1234::1234:1234:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

ฉันไม่สามารถรับแพ็กเก็ตของพฤติกรรมนี้ การเรียกใช้คำสั่ง ping นี้ (ล้มเหลว) จะไม่สร้างแพ็กเก็ตใด ๆ ใน Microsoft Network Monitor ในทำนองเดียวกันการพยายามเชื่อมต่อกับmstsc.exeโฮสต์ที่มีAAAAเร็กคอร์ดจะไม่สร้างทราฟฟิกจนกว่าจะกลับไปสู่ ​​IPv4

อัปเดต:โฮสต์ของเราทั้งหมดใช้ที่อยู่ IPv4 ที่กำหนดเส้นทางได้แบบสาธารณะ ฉันคิดว่าปัญหานี้อาจเกิดจากการกำหนดค่า 6to4 ที่เสีย 6to4 จะทำงานแตกต่างกันไปตามโฮสต์ที่มีที่อยู่ IP สาธารณะและที่อยู่ RFC1918

ปรับปรุง:มีบางสิ่งบางอย่างคาวกับ 6to4 ในเครือข่ายของฉัน เมื่อฉันปิดการใช้งาน 6to4 บนไคลเอนต์ Windows การเชื่อมต่อจะแก้ไขทันที

netsh int ipv6 6to4 set state disabled

แต่อย่างที่ @joeqwerty พูดว่านี่เป็นการปกปิดปัญหาเท่านั้น ฉันยังคงพยายามหาสาเหตุที่การสื่อสาร IPv6 บนเครือข่ายของเราไม่ทำงานอย่างสมบูรณ์

คำถามนี้น่าสนใจทีเดียวและฉันต้องยอมรับว่าฉันไม่เคยเห็นพฤติกรรมนี้เลย ในการลองเล่นไปรอบ ๆ เพื่อลองและทำความเข้าใจให้ดีขึ้นฉันเอาตัวอย่างของการค้นหา nslookup สำหรับหนึ่งในเซิร์ฟเวอร์ W2K8R2 RDS ของฉันจากเซิร์ฟเวอร์ W2K8R2 อื่นและฉันก็จับตัวอย่างของเซสชัน RDP ไปยังเซิร์ฟเวอร์ RDS เดียวกันจากเซิร์ฟเวอร์ทดสอบเดียวกัน . Nslookup ไม่พบความล่าช้าในการส่งคืนบันทึก IPv6 และ nslookup แสดงให้เห็นว่าเซิร์ฟเวอร์ทดสอบของฉันทำการสืบค้นระเบียน IPv4 ก่อนที่จะทำการสอบถามระเบียน IPv6 เวลาเดลต้าในการดักจับแสดงว่าไม่มีการหน่วงเวลาที่มองเห็นได้ (ซึ่งฉันสามารถตรวจสอบได้) ในการสืบค้นใด ๆ

แก้ไข

ตอนนี้คุณกำลังจะทำอะไรบางอย่าง

ตรวจสอบให้แน่ใจว่าคุณจับภาพทราฟฟิกสำหรับอะแดปเตอร์ Microsoft 6To4 มิฉะนั้นคุณจะไม่เห็น IPv6:

นี่คือผลลัพธ์ nslookup สำหรับเซิร์ฟเวอร์ RDS ของฉัน จดบันทึกที่อยู่ IPv6:

ตอนนี้นี่เป็นตัวอย่างข้อมูลที่ฉันจับ:

และสุดท้ายนี่คือตัวอย่างข้อมูลจาก netstat ที่แสดงการเชื่อมต่อ:

อย่างชัดเจนเมื่อคุณยืนยันการแก้ไข DNS ไม่ใช่ปัญหา ปัญหาคือว่าการเชื่อมต่อ RDP ชอบ IPv6 มากกว่า IPv4 (ซึ่งเป็นค่าเริ่มต้นสำหรับ Windows - Windows ต้องการ IPv6 มากกว่า IPv4) และเนื่องจาก IPv6 ทำงานไม่ถูกต้องมันทำให้เกิดความล่าช้า (ตามที่คุณระบุไว้) เมื่อถอยกลับจาก IPv6 เพื่อ IPv4 คุณสามารถแก้ไขได้โดยการกำหนดค่าไคลเอนต์ให้ชอบ IPv4 มากกว่า IPv6 แต่ฉันคิดว่ามันน่าจะแก้ปัญหาได้ ทางออกที่ดีกว่าคือการหาสาเหตุที่ IPv6 ไม่ทำงานและแก้ไขปัญหานั้น ฉันไม่รู้เพียงพอเกี่ยวกับ IPv6 ที่จะช่วยได้ แต่ฉันเดาได้ว่าระเบียน IPv6 ที่ส่งคืนโดย DNS เป็นที่อยู่ "ท้องถิ่น" ที่ถูกต้องเฉพาะบนซับเน็ตที่มีโฮสต์ RDS อยู่และเนื่องจากไคลเอ็นต์อยู่ในเครือข่ายย่อยอื่นพวกเขาสามารถ ' ไม่สามารถเข้าถึงที่อยู่ IPv6 เหล่านั้นได้

เทคโนโลยีการเปลี่ยนผ่าน IPv6 ที่เรียกว่า 6to4 นั้นน่าอับอายที่ทำให้เกิดปัญหาเช่นนี้ มีหลายปัจจัยในที่ทำงาน ทีละอย่างพวกเขาจะไม่เป็นอันตราย แต่ผลรวมกันคือผู้ใช้สามารถประสบความล่าช้าในการเชื่อมต่อ

รายการปัจจัยที่เปิดใช้งานและความคิดเกี่ยวกับการบรรเทาของพวกเขาจะถูกนำเสนอด้านล่าง

Windows เปิดใช้งาน 6to4 ตามค่าเริ่มต้น

หากโฮสต์ของคุณกำลังเรียกใช้ Windows รุ่นล่าสุด (Vista หรือใหม่กว่า) Windows จะเปิดใช้งาน 6to4 tunneling โดยอัตโนมัติเมื่อมีที่อยู่ IPv4 ที่สามารถกำหนดเส้นทางสาธารณะได้ วิกฤตนี้นำไปใช้กับเซิร์ฟเวอร์และลูกค้า

เพื่อหาข้อมูลว่าระบบใช้ 6to4 วิ่งipconfigและมองหาที่อยู่ IPv6 2002:ที่เริ่มต้นด้วยคำนำหน้า มันจะมีลักษณะเช่นนี้

C:\> ipconfig
Tunnel adapter 6TO4 Adapter:
IPv6 Address. . . . . . . . . . . : 2002:1111:2222::1111:2222

• หากปลายทางของคุณเชื่อมต่อกับ Active Directory คุณสามารถใช้นโยบายกลุ่มเพื่อปิดใช้งานโปรโตคอลการเปลี่ยนเช่น 6to4 และ Teredo นี้เป็นอย่างดีการบันทึกไว้ในKB929852 (การใช้สิ่งนี้กับลูกค้าหรือเซิร์ฟเวอร์ของคุณจะเพียงพอ แต่ถ้าคุณทำตามขั้นตอนนี้อาจเป็นการดีที่จะปิดการใช้งานได้ทุกที่ทั้งบนไคลเอนต์และเซิร์ฟเวอร์)
• หากคุณจัดการโฮสต์เพียงไม่กี่แห่งคุณสามารถปิดใช้งาน 6to4 เป็นกรณี ๆ ไป นี่ดีกว่าปิดการใช้งาน IPv6 อย่างสิ้นเชิงnetsh int ipv6 6to4 set state disabled
• ใช้ระบบปฏิบัติการไคลเอนต์อื่น ตัวอย่างเช่น Mac OS X ไม่มีการเปิดใช้งาน 6to4 โดยค่าเริ่มต้น

มีการใช้ที่อยู่ IPv4 ที่กำหนดเส้นทางสาธารณะได้

6to4 ใช้งานได้เฉพาะกับโฮสต์ที่มีที่อยู่ IPv4 ที่กำหนดเส้นทางได้สาธารณะดังนั้นปัญหานี้จะไม่ส่งผลกระทบต่อโฮสต์ที่อยู่หลังไฟร์วอลล์ NAT

• คุณสามารถย้ายไคลเอนต์และ / หรือเซิร์ฟเวอร์ที่อยู่หลังไฟร์วอลล์ NAT และเริ่มใช้การกำหนดแอดเดรส RFC1918 แต่ในบางกรณีที่อยู่ที่กำหนดเส้นทางได้สาธารณะเป็นที่ต้องการจริง การเปลี่ยนที่อยู่ของเครือข่ายทั้งหมดอาจเป็นตัวเลือกที่ไม่สมจริง

6to4 ทำงานไม่ถูกต้องบนเครือข่าย

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

โดยย่อ 6to4 ทำงานโดยการห่อหุ้มแพ็กเก็ต IPv6 ลงในแพ็กเก็ต IPv4 โดยใช้โปรโตคอลที่เรียกว่า 6in4 (โปรโตคอล IP = 41) แพ็คเก็ต IPv4 นั้นจะถูกส่งไปยังที่อยู่ใด ๆ ของการออกอากาศ192.88.99.1ด้วยความหวังว่ามันจะมาถึงรีเลย์ 6to4 ที่ทำงานอยู่ที่ไหนสักแห่งบนอินเทอร์เน็ต มันอาจอยู่ใกล้คุณในเชิงภูมิศาสตร์ถ้าคุณโชคดี

ในทางปฏิบัติมีการตั้งค่ารีเลย์ 6to4 อย่างไม่ถูกต้องและเครือข่ายจำนวนมากไม่อนุญาตให้มีการรับส่งข้อมูล 6in4 ข้ามไฟร์วอลล์ โดยทั่วไปแล้วสิ่งนี้จะเกิดขึ้นเมื่อไฟร์วอลล์อนุญาตการรับส่งข้อมูลขาออกทั้งหมด แต่ไม่อนุญาตให้มีโปรโตคอล IP 41 แพ็กเก็ตเพื่อส่งคืนผ่านไฟร์วอลล์อย่างชัดเจน (สิ่งที่ต้องทำทราบ RFC ที่เกี่ยวข้องสำหรับการแก้ไขปัญหา.) ความล้มเหลวนี้ ( "หลุมดำขาเข้า") และอื่น ๆ อีกมากมายที่อธิบายไว้ในRFC 6343

• ตั้งค่าไฟร์วอลล์ของคุณให้ปฏิเสธโปรโตคอล IP ดัง 41 (ด้วยการรีเซ็ต TCP) เมื่อส่งจากโฮสต์ภายในเครือข่ายของคุณ สิ่งนี้จะส่งผลให้เกิดพฤติกรรม "ล้มเหลวเร็ว" ที่เหมาะสมกว่าการเชื่อมต่อที่ไม่ได้กำหนดไว้ นี้ได้รับการแสดงให้เห็นถึงการทำงานในสภาพแวดล้อมการทดสอบ จำกัด
• สอบถาม ISP หรือผู้ให้บริการขนส่งรายแรกของคุณเพื่อตั้งค่ารีเลย์ 6to4 ที่ใช้งานได้ หากสิ่งนี้ถูกต้องมันจะส่งผลให้ผู้ใช้ปลายทางได้รับประสบการณ์ที่ดีที่สุด ผู้ใช้ปลายทางที่มีที่อยู่ IPv4 ที่กำหนดเส้นทางได้แบบสาธารณะจะสามารถเข้าร่วมในอินเทอร์เน็ต IPv6 ได้

การลงทะเบียน DNS แบบไดนามิก

ในสภาพแวดล้อม Active Directory ทั่วไปคอมพิวเตอร์ทุกเครื่องได้รับอนุญาตให้ลงทะเบียนที่อยู่ของตัวเองกับเซิร์ฟเวอร์ DNS เมื่อโฮสต์มีหลายรูปแบบโฮสต์จะลงทะเบียนที่อยู่ทั้งหมดแม้จะมาจากอุโมงค์ 6to4

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

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

แอปพลิเคชันไคลเอ็นต์ไม่ได้ล้มเหลวอย่างงดงาม

ไคลเอนต์ RDP ของ Microsoft เป็นตัวอย่างหนึ่งของแอปพลิเคชันไคลเอนต์ที่ไม่ได้จัดการกับปัญหาการกำหนดเส้นทาง IPv6 อย่างสง่างาม เว็บเบราว์เซอร์ส่วนใหญ่ดีกว่าในการจัดการกับกรณีขอบ IPv6 เช่นนี้ดังนั้นพวกเขาจึงไม่มีแนวโน้มที่จะแสดงพฤติกรรมนี้

• ลองใช้ไคลเอนต์อื่น บางทีคุณอาจจะโชคดี

ฉันรู้ว่ามันไม่เป็นประโยชน์มากสำหรับสถานการณ์นี้ แต่สำหรับผู้ดำเนินการที่เผชิญกับภาวะที่กลืนไม่เข้าคายไม่ออกมีเทคนิคการใช้งานที่เรียกว่า"Happy Eyeballs" (RFC 6555) ที่ระบุเทคนิคสำหรับการเชื่อมต่อกับ ipv4 และ ipv6 พร้อมกัน

นี่คือทางออกของฉัน โดยค่าเริ่มต้น Windows ให้เส้นทาง IPv6 มีลำดับความสำคัญสูงกว่าเส้นทาง IPv4 หากคุณแก้ไขนโยบายคำนำหน้า IPv6 คุณสามารถเปลี่ยนพฤติกรรมนี้เพื่อให้ใช้งาน IPv4 ได้ตามต้องการกับ IPv6

เพื่อให้แน่ใจว่าระบบทั้งหมดในเครือข่ายของฉันมีการตั้งค่าแบบเดียวกันฉันใส่คำสั่งต่อไปนี้ลงในสคริปต์. bat ที่รันระหว่างการติดตั้งซอฟต์แวร์หลังจากสร้างหรือปรับปรุงเครื่องใหม่

netsh int ipv6 isatap set state disabled
netsh int ipv6 6to4 set state disabled
netsh interface teredo set state disable

netsh interface ipv6 delete prefixpolicy ::1/128
netsh interface ipv6 delete prefixpolicy ::/0
netsh interface ipv6 delete prefixpolicy 2002::/16
netsh interface ipv6 delete prefixpolicy ::/96
netsh interface ipv6 delete prefixpolicy ::ffff:0:0/96
netsh interface ipv6 delete prefixpolicy 2001::/32

netsh interface ipv6 add prefixpolicy ::1/128 50 0
netsh interface ipv6 add prefixpolicy ::ffff:0:0/96 40 1
netsh interface ipv6 add prefixpolicy ::/0 30 2
netsh interface ipv6 add prefixpolicy 2002::/16 20 3
netsh interface ipv6 add prefixpolicy ::/96 10 4
netsh interface ipv6 add prefixpolicy 2001::/32 5 5

เพื่ออธิบายสิ่งนี้ทำอะไร:

3 บรรทัดแรกปิดใช้งานอินเทอร์เฟซการทันเนลในตัวเนื่องจากเป็นเครือข่ายส่วนใหญ่ซ้ำซ้อน คุณอาจไม่ต้องการใช้ 3 บรรทัดเหล่านี้หากคุณไม่ได้ให้ที่อยู่ IPv6 ของเครื่องของคุณเองในกรณีของฉันฉันมีเซิร์ฟเวอร์ DHCPv6 และโครงสร้างพื้นฐานที่เกี่ยวข้องกำหนด IPv6 สำหรับการเชื่อมต่อแบบช่องสัญญาณ

คำสั่งบล็อกที่สองจะลบนโยบายคำนำหน้าการกำหนดเส้นทาง IPv6 ที่มีอยู่ทั้งหมด

บล็อกที่สามจะสร้างนโยบายคำนำหน้า IPv6 ใหม่ แต่ใช้ลำดับความสำคัญชุดอื่น เช่นเดียวกับคำนำหน้าที่สอดคล้องกับ IPv4 จะได้รับการกำหนดค่าตามความชอบมากกว่า IPv6 และเครื่องจะต้องการใช้ IPv4 เว้นแต่ว่าแอปพลิเคชันจะระบุการใช้งานของ IPv6

โซลูชันนี้ยังคงความสามารถในการใช้งานแบบ dual-stack แต่การกำหนดค่าเพื่อใช้งาน IPv4 หมายความว่าไซต์ที่มี IPv6 ที่ไม่สมบูรณ์ไม่น่าเชื่อถือหรือมีประสิทธิภาพต่ำจะหลีกเลี่ยงการใช้งานเว้นแต่จะได้รับคำสั่งจากโปรแกรมบนระบบ

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