ทำไมเส้นทางโฮสต์ /32 จึงทำให้จุดสิ้นสุด VPN เข้าถึงได้
เส้นทางโฮสต์เลือกที่อยู่เดียว ไม่ใช่ซับเน็ต มันอาจทำให้จุดสิ้นสุดของอุโมงค์เข้าถึงได้หรือตรึงทรัพยากรหนึ่งอย่าง แต่จะล้าสมัยเมื่อที่อยู่เปลี่ยน
เมื่อเชื่อมต่อแล้วเปิดตารางเส้นทางจะพบที่อยู่หนึ่งรายการถูกส่งผ่านอุโมงค์ ขณะที่ซับเน็ตรอบๆ ยังคงไปยังเกตเวย์ท้องถิ่น รายการนั้นคือเส้นทางโฮสต์: ที่อยู่เดียว จับคู่ด้วยคำนำหน้าที่เป็นหนึ่งทั้งหมด สิ่งนี้สำคัญเพราะการตัดสินใจเลือกเส้นทางใช้คำนำหน้าที่ตรงกันยาวที่สุด ดังนั้น /32 จึงเอาชนะ /24 หรือเส้นทางเริ่มต้นได้โดยไม่ต้องเปลี่ยนทั้งสองรายการ การที่มันเป็นข้อยกเว้นที่รอบคอบหรือการล่มในอนาคตขึ้นอยู่กับว่ามันระบุที่อยู่ใดและใครดูแลมัน
ที่อยู่เดียว หนึ่งรายการในตาราง
เส้นทางโฮสต์ IPv4 มีคำนำหน้า /32 และเส้นทางโฮสต์ IPv6 มี /128 ซึ่งหมายความว่ารายการสามารถตรงกับที่อยู่ปลายทางได้เพียงหนึ่งเดียว ไม่มีสิ่งอื่นในตารางเคลื่อนไหว: ซับเน็ตที่ครอบคลุมและเส้นทางเริ่มต้นยังคงอยู่ที่เดิม รายการแคบชนะสำหรับที่อยู่นั้นเพราะคำนำหน้ายาวกว่า ไม่ใช่เพราะถูกเพิ่มภายหลัง
คุณสมบัตินั้นทำให้เส้นทางโฮสต์เป็นข้อยกเว้นที่ดีและเป็นนิสัยที่ไม่ดี สองรายการ /32 ที่ระบุประตูหน้าของบริการไม่ครอบคลุมที่อยู่ที่สอง ที่อยู่ IPv6 หรือที่อยู่ที่มันจะย้ายไปเดือนหน้า ตารางที่เต็มไปด้วยรายการที่อยู่เดียวซึ่งไม่ได้อธิบายมักหมายความว่ามีคนคอยปะชุนรอบการตัดสินใจเรื่องซับเน็ตแทนที่จะตัดสินใจ อ่านความยาวคำนำหน้าก่อน แล้วถามว่ารายการนั้นควรปกป้องอะไร
อ่านรายการจากไคลเอนต์ออกไปด้านนอก
เริ่มจากเครื่องที่มีปัญหาก่อน เพราะที่อยู่เดียวกันอาจถูกส่งเส้นทางต่างกันบนแล็ปท็อปและบนเกตเวย์ที่อยู่ข้างหน้า ถามเคอร์เนลว่าจะเลือกเส้นทางใดสำหรับที่อยู่ที่แอปพลิเคชันใช้จริง แทนที่จะอ่านตารางจากด้านบน คำตอบรวมถึง อินเทอร์เฟซและฮ็อปถัดไป ซึ่งรวมกันเป็นการตัดสินใจ
ip route get 203.0.113.25
ip -6 route get 2001:db8:4::25
ip route show | grep -F 203.0.113.25
Find-NetRoute -RemoteIPAddress 203.0.113.25ทำซ้ำคำถามสำหรับตระกูลที่อยู่ที่แอปพลิเคชันเลือกจริง เพราะไคลเอนต์อาจเลือก IPv6 และข้ามข้อยกเว้น IPv4 อย่างเงียบๆ เปรียบเทียบผลก่อนและหลังอุโมงค์ขึ้น และเก็บผลลัพธ์ทั้งสองไว้ การเปรียบเทียบนั้นแสดงว่าไคลเอนต์เพิ่มรายการตอนเชื่อมต่อหรือมันมีอยู่แล้ว
รายการถาวรและรายการขณะทำงานล้มเหลวต่างกัน รายการขณะทำงานหายไปพร้อมเซสชัน ส่วนรายการถาวรอยู่รอดหลังรีบูตและยังคงส่งทราฟฟิกไปยังเกตเวย์ที่ไม่มีอยู่แล้ว
ข้อยกเว้นของจุดสิ้นสุดและกับดักการวนซ้ำ
ไคลเอนต์ VPN มักติดตั้ง เส้นทางโฮสต์ไปยังที่อยู่ภายนอกของเซิร์ฟเวอร์ ผ่านเกตเวย์เดิมก่อนเปลี่ยนเส้นทางเริ่มต้น หากไม่มีรายการนั้น แพ็กเก็ตที่เข้ารหัสจะถูกส่งเข้าไปในอุโมงค์ที่กำลังพยายามสร้าง และการเชื่อมต่อจะวนซ้ำจนหมดเวลา
กับดักปรากฏเมื่อซับเน็ตที่ยอมรับของอุโมงค์บังเอิญมีที่อยู่จุดสิ้นสุดนั้น หรือเมื่อโปรไฟล์ที่สองเพิ่มเส้นทางที่กว้างกว่าในภายหลัง รายการจุดสิ้นสุดจะแพ้คำนำหน้าที่ยาวกว่าและเซสชันจะพังทันทีที่เริ่มส่งทราฟฟิกผ่าน การเขียนที่อยู่จุดสิ้นสุดไว้ข้างซับเน็ตที่ยอมรับเป็นวิธีที่ถูกที่สุดในการสังเกตการชนก่อนผู้ใช้ และยังอธิบายว่าทำไมโปรไฟล์เดียวกันจึงทำงานได้จากเครือข่ายหนึ่งและล้มเหลวจากอีกเครือข่ายหนึ่ง
ตรวจสอบเส้นทางที่แอปพลิเคชันใช้จริง
ping ที่สำเร็จไปยังชื่อโฮสต์เป็นหลักฐานอ่อนเมื่อแอปพลิเคชันเชื่อมต่อกับที่อยู่อื่นหรือตระกูลอื่น ตรวจสอบการรวมกันที่แน่นอนของที่อยู่ ตระกูล พอร์ต และอินเทอร์เฟซ จากเครื่องที่รันไคลเอนต์
ip route get 203.0.113.25
sudo nft list ruleset | grep -A 4 'chain output'
curl -sS --max-time 8 -o /dev/null -w '%{remote_ip}
' https://app.example.netหากเส้นทางผิด ให้ตัดสินว่าความต้องการคือเครือข่ายหรือที่อยู่เดียว ก่อนแก้ไขสิ่งใด ความต้องการที่อยู่เดียวทำให้เส้นทางโฮสต์มีเหตุผลพร้อมความคิดเห็นและเจ้าของ ส่วนบริการที่มีที่อยู่หมุนเวียนต้องใช้การกำหนดเส้นทางตามโดเมนหรือการตัดสินใจเรื่องซับเน็ตอย่างตรงไปตรงมา
ลบรายการที่ไม่ตรงกับปลายทางจริงแล้ว และบันทึกรายการที่คุณเก็บไว้ /32 ที่ไม่ได้อธิบายจะแยกจากบั๊กไม่ได้ในอีกสามเดือน และคนถัดไปจะลบมันโดยไม่รู้ว่าอะไรที่พึ่งพามันอยู่