ที่อยู่ความเป็นส่วนตัว IPv6 หรือรายการอนุญาต RDP: เลือกการแลกเปลี่ยน

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

ทำไมกฎจึงเลิกตรงกัน

RFC 4941 อธิบายที่อยู่ชั่วคราว: โฮสต์สร้างที่อยู่เพิ่มเติมด้วยตัวระบุแบบสุ่มและเลิกใช้ ซึ่งป้องกันผู้สังเกตจากการเชื่อมโยงโฮสต์เดียวข้ามการเยี่ยมชม Windows ใช้พฤติกรรมนั้น ดังนั้นที่อยู่ต้นทางของเมื่อวานจึงไม่จำเป็นต้องเป็นของวันนี้ ที่อยู่ที่คาดเดาได้ยังมีอยู่บนอินเทอร์เฟซ เพียงแต่ไม่ใช่ที่อยู่ที่การเชื่อมต่อขาออกเลือกใช้

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

ทางเลือกที่หนึ่ง: ที่อยู่คงที่หนึ่งที่ ความเป็นส่วนตัวน้อยลง

การซ่อมแซมตามปกติปิดกลไกการหมุนทั้งสองบนโฮสต์: netsh interface ipv6 set privacy state=disabled store=persistent และ netsh interface ipv6 set global randomizeidentifiers=disabled store=persistent เพิ่ม store=active หากต้องการให้การเปลี่ยนแปลงมีผลโดยไม่ต้องรอรีสตาร์ท และยอมรับว่าคุณทำให้ตัวระบุคาดเดาได้ข้ามเครือข่ายแล้ว

ความคาดเดาได้นั้นคือสิ่งที่ส่วนขยายถูกสร้างขึ้นเพื่อป้องกัน ที่อยู่ที่ตามโฮสต์จากคาเฟ่ไปออฟฟิศและกลับบ้านเป็นกุญแจกรองที่สะดวกและเป็นกุญแจติดตามที่สะดวกพอๆ กัน และคุณสมบัติที่สองมีอายุยืนกว่าตั๋วที่ขอคุณสมบัติแรก

ทางเลือกที่สอง: อนุญาตคำนำหน้าหรือชื่อ

การอนุญาต /64 แทนที่อยู่เต็มช่วยรักษาการหมุนไว้ได้และตรงกับข้ออ้างที่อ่อนกว่าแต่ซื่อสัตย์บ่อยครั้ง: เครื่องนี้อยู่ในเครือข่ายบ้านของฉัน มันหยุดเพียงพอในทันทีที่คำนำหน้านั้นมีโฮสต์ที่คุณจะไม่รับ ซึ่งบนการเชื่อมต่อผู้บริโภคมักเป็นชุดที่เล็กกว่าที่คนคิด ชื่อที่เผยแพร่ผ่าน DNS แบบไดนามิกนั้นดูแลง่ายกว่า เพราะระเบียนตามโฮสต์และนโยบายอ่านเป็นตัวตนไม่ใช่ช่วงที่ขยายทุกครั้งที่เพิ่มอุปกรณ์

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

ทางเลือกที่สาม: ให้อุโมงค์กำหนดที่อยู่

หากการเชื่อมต่อผ่าน VPN ที่คุณควบคุม เซิร์ฟเวอร์สามารถแจกที่อยู่จากพูลของตัวเอง และรายการอนุญาตอ้างถึงค่าที่เซิร์ฟเวอร์เลือกแทนค่าที่ไคลเอนต์ต้องการ สิ่งนี้ทำงานได้ดีกับไคลเอนต์ที่จัดการและแย่กับทุกสิ่งที่ไคลเอนต์สามารถแทนที่ได้ ดังนั้นตรวจสอบว่าฝ่ายใดชนะจริงในการติดตั้งของคุณ

การย้ายการตัดสินใจออกจากที่อยู่ทั้งหมด ไปยังใบรับรองไคลเอนต์หรือเกตเวย์ที่ผ่านการพิสูจน์ตัวตน คือทางเลือกที่ขยายได้ เพราะมันเลิกพึ่งพาค่าที่ระบบปฏิบัติการมีสิทธิ์เปลี่ยน

เลือกโดยคำนึงถึงต้นทุนการติดตาม

เขียนสี่ทางเลือกเทียบกับความต้องการจริง และเลือกหนึ่งแทนการรวมกัน หากคุณปิดความเป็นส่วนตัวอยู่ดี ให้จำกัดไว้ที่โฮสต์ที่ต้องการ บันทึกเหตุผลข้างกฎ และพิจารณาการกำหนดที่อยู่แบบคงที่-ส่วนตัวจาก RFC 7217 ในที่ที่แพลตฟอร์มรองรับ เพราะมันเก็บตัวระบุต่อคำนำหน้าโดยไม่เปิดเผยตัวที่ได้จากฮาร์ดแวร์ เปิดส่วนขยายอีกครั้งเมื่อรายการอนุญาตถูกแทนที่

บันทึกการเปลี่ยนแปลงข้างกฎที่มันรองรับ หากไม่มีบันทึกนั้น ผู้ดูแลคนถัดไปจะพบโฮสต์ที่ปิดส่วนขยายความเป็นส่วนตัวและไม่มีคำอธิบาย และเปิดมันกลับระหว่างการทำความสะอาด