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

สองการค้นหา ไม่ใช่หนึ่ง

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

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

อ่านกฎเป็นการแข่งขันที่เรียงลำดับ

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

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

สังเกตด้วยว่านี่คือครึ่งหนึ่งด้านแหล่งของปัญหา การผสมการเปรียบเทียบคำนำหน้าสองแบบเข้าด้วยกันทำให้เกิดคำอธิบายที่ฟังดูเข้มงวดแต่ทำนายที่อยู่ผิด ทุกครั้งที่ใช้คำว่าคำนำหน้าในตั๋ว จงระบุว่าหมายถึงการเปรียบเทียบใด

การผูกแอปพลิเคชันเปลี่ยนคำถาม

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

สิ่งนี้ทำให้การผูกแหล่งเป็นทั้งเครื่องมือวินิจฉัยและวิธีแก้ชั่วคราว: ผูกที่อยู่ VPN และดูว่าคำขอสำเร็จหรือไม่ หากสำเร็จ เส้นทางก็ดีและปัญหาคือการเลือก หากล้มเหลว ปัญหาคือเส้นทางขากลับหรือนโยบายของฝั่งไกลมาตลอด

ตรวจสอบว่าฝั่งไกลยอมรับแหล่งนั้น

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

เก็บที่อยู่ปลายทางภายนอกไว้แยกต่างหากในการให้เหตุผลของคุณด้วย มันระบุการขนส่งระหว่างผู้เข้าร่วม VPN และไม่ใช่แหล่งของแพ็กเก็ตแอปพลิเคชันภายใน

ตัดสินด้วยการสังเกตสี่ประการ

บันทึกปลายทางที่ใช้ แหล่งท้องถิ่นที่มีสิทธิ์ แหล่งที่เลือกจริง และเส้นทางขาออกที่มีผล สี่บรรทัดก็เพียงพอที่จะอธิบายเกือบทุกกรณี และสามารถเปรียบเทียบระหว่างโฮสต์ที่ทำงานได้กับที่ล้มเหลวโดยไม่ต้องถกเถียงทฤษฎีใหม่ สำหรับขั้นตอนการเลือกให้ใช้มุมมองที่รองรับของระบบปฏิบัติการเองแทนชื่อจากมาตรฐาน เพราะการนำไปปฏิบัติเพิ่มการตั้งค่าเฉพาะถิ่นของตน

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

บทความที่เกี่ยวข้อง