VPN เซิร์ฟเวอร์ที่บ้านเข้าถึงไม่ได้: เดินตามห่วงโซ่ NAT

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

เริ่มจากหน้า WAN ของเราเตอร์

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

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

ขึ้นไปหนึ่งฮอป

รัน traceroute จากตัวเราเตอร์เองและอ่านฮอปแรกๆ ที่อยู่สาธารณะที่ซ้ำกัน ฮอปแรกที่ตอบด้วยที่อยู่ส่วนตัว หรือที่อยู่ในช่วงที่ใช้ร่วมกัน 100.64.0.0/10 ล้วนชี้ไปที่ตัวแปลที่อยู่เหนือขึ้นไป RFC 6598 กำหนดช่วงนั้นไว้สำหรับการติดตั้งแบบนี้โดยเฉพาะ จึงเป็นการเห็นที่ให้สัญญาณหนักแน่น ไม่ใช่ความแปลกประหลาด หากมีตัวแปลสองตัวในเส้นทาง ร่องรอยจะชัดน้อยลง ดังนั้นอ่านรูปแบบไม่ใช่เพียงบรรทัดเดียว

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

ยืนยันตัวรับฟังและการส่งต่อ

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

ss -lunp | grep -E '1194|51820'
ip -4 addr show | grep -E 'inet '
curl -s --max-time 5 ifconfig.me
traceroute -n -m 5 1.1.1.1

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

เปลี่ยนโครงสร้างเครือข่าย ไม่ใช่กฎเดิม

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

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

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