DS-Lite บล็อกโฮสติ้ง IPv4 ขาเข้า ไม่ใช่ VPN ขาออก

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

ฝ่ายใดเริ่มการเชื่อมต่อ

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

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

ติดตามคำขอขาออก

สถาปัตยกรรมใน RFC 6333 ระบุชื่อทั้งสองปลาย องค์ประกอบฝั่งลูกค้าคือ B4 ซึ่งห่อ IPv4 ไว้ใน IPv6 องค์ประกอบฝั่งผู้ให้บริการคือ AFTR ซึ่งทำการแปลที่อยู่และส่งต่อแพ็กเก็ตเป็น IPv4

Client's IPv4 VPN packet
  → Customer B4
  → IPv4 carried over the provider's IPv6 network
  → AFTR address translation
  → IPv4 VPN server

เซิร์ฟเวอร์ VPN ได้รับการเชื่อมต่อ IPv4 ปกติจากที่อยู่ที่แปลแล้วของผู้ให้บริการ ไม่ต้องใช้โหมด DS-Lite พอร์ตพิเศษ หรือความรู้ว่าเครือข่ายการเข้าถึงของลูกค้าเป็น IPv6 เท่านั้น นี่คือส่วนที่ผู้คนมองข้าม ปลายทางไกลไม่อาจรู้ได้

การกำหนดค่าของไคลเอนต์เองก็ธรรมดาเช่นกัน ต้องมีเส้นทาง IPv4 ที่ใช้งานได้ไปยังเซิร์ฟเวอร์ ซึ่ง B4 และ AFTR จัดให้ และต้องให้ชื่อโฮสต์ของเซิร์ฟเวอร์แปลงเป็นที่อยู่ IPv4

เหตุใดโฮสติ้งขาเข้าจึงเป็นกรณีที่ล้มเหลว

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

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

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

วินิจฉัยก่อนเปลี่ยนแผนการเข้าถึง

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

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

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

อ่านการเปลี่ยนแปลงของผู้ให้บริการอย่างระมัดระวัง

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

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

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