NAT ซ้อนสองชั้นกับ VPN ของคุณ: ไคลเอนต์ใช้ได้ แต่เซิร์ฟเวอร์ใช้ไม่ได้

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

วาดทิศทางของการเชื่อมต่อก่อน

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

curl -s https://ifconfig.me
ip -brief address
traceroute -n 1.1.1.1

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

ขาออก: ไคลเอนต์ถาม ตัวแปลงจับคู่

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

ความล้มเหลวที่เกิดขึ้นจริงมักเกี่ยวกับการหมดเวลาและการรองรับโปรโตคอล ไม่ใช่จำนวนเราเตอร์ อุโมงค์ที่หลุดหลังความเงียบไม่กี่นาทีคือการจับคู่ที่หมดอายุ และ keepalive คือคำตอบมาตรฐาน IPsec มีส่วนขยาย NAT-traversal มาตรฐาน ดังนั้นการอ้างว่ามันข้ามการแปลงไม่ได้จึงเป็นเพียงข้อผิดพลาด อุโมงค์ที่ไม่เกิดขึ้นเลย ให้ดูที่ปลายทางและข้อมูลรับรองก่อนจะโทษโครงสร้างเครือข่าย

wg show
ping -c3 10.8.0.1

หยุดถ้าอุโมงค์ขาออกทำงานจากเครือข่ายหนึ่งแต่ไม่อีกเครือข่ายหนึ่ง การเปรียบเทียบนั้นเป็นเรื่องของเครือข่าย ไม่ใช่จำนวนเราเตอร์

ขาเข้า: การส่งต่อครอบคลุมเฉพาะอุปกรณ์ที่คุณเป็นเจ้าของ

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

nc -vz 203.0.113.10 51820
ss -lunp 'sport = :51820'

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

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

ทดสอบทีละตัวแปร

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

journalctl -u wg-quick@wg0 -n 30 --no-pager
ip route get 10.20.30.40

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

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