ทำไมหน้าแอดมินของเราเตอร์จึงหยุดตอบหลังเปลี่ยน VPN

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

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

อุโมงค์ไม่เคยเป็นเส้นทางการจัดการ

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

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

ชั้นแรก มีเส้นทางไปยังที่อยู่ของเราเตอร์เองหรือไม่

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

ฝั่งอุโมงค์มีคำถามอีกเวอร์ชันหนึ่ง WireGuard มอง AllowedIPs เป็นตารางเส้นทางคีย์เข้ารหัส แต่ละปลายประกาศว่าที่อยู่ต้นทางใดที่เพียร์ใช้ได้และปลายทางใดที่ส่งไปยังเพียร์นั้น หากรายการของไคลเอนต์ไม่รวมที่อยู่ tunnels ของเราเตอร์ ไคลเอนต์ก็ไม่มีเส้นทางไปที่นั่น หากรายการของเซิร์ฟเวอร์สำหรับไคลเอนต์นั้นไม่ครอบคลุมที่อยู่ tunnels ของไคลเอนต์ เซิร์ฟเวอร์จะทิ้งแพ็กเก็ตก่อนที่จะดูกฎไฟร์วอลล์ใด ๆ

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

ชั้นที่สอง นโยบายขาเข้า ไม่ใช่นโยบายการส่งต่อ

ไฟร์วอลล์ประเมินกฎบนอินเทอร์เฟซที่แพ็กเก็ตมาถึง บน pfSense และ OPNsense แท็บอินเทอร์เฟซและลำดับกฎเป็นตัวกำหนดว่าทราฟฟิกไปยังบริการของไฟร์วอลล์เองได้รับอนุญาตหรือไม่ กฎที่ปล่อยไคลเอนต์ LAN ออกอินเทอร์เน็ตไม่ใช่กฎที่อนุญาตให้เพียร์ของอุโมงค์เปิดเว็บ GUI บน OpenWrt ที่ใช้ firewall4 แต่ละโซนมีนโยบายขาเข้า option input 'ACCEPT' หรือ 'REJECT' และอินเทอร์เฟซอุโมงค์ในโซนที่ขาเข้าเป็น REJECT จะปฏิเสธการเชื่อมต่อเพื่อจัดการ ขณะที่ยังส่งต่อทราฟฟิกหากอนุญาตให้ส่งต่อ

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

# on the router: bind addresses and the loaded ruleset
ss -ltnp | grep -E ':(22|80|443)\b'         # Linux / OpenWrt
sockstat -4 -l | grep -E ':(22|80|443)\b'   # FreeBSD / pfSense
nft list ruleset | grep -A6 'chain input'    # firewall4
pfctl -sr | head -40                         # pf / pfSense

ชั้นที่สาม มีอะไรฟังอยู่บนที่อยู่นั้นหรือไม่

บริการอาจทำงานอยู่แต่เข้าถึงไม่ได้เพราะผูกกับที่อยู่เดียว uhttpd ของ OpenWrt เก็บรายการฟังที่ชัดเจนไว้ใน /etc/config/uhttpd เช่น list listen_http '0.0.0.0:80' บิลด์ที่ผูกกับที่อยู่ LAN เท่านั้นจะไม่รับอะไรบนที่อยู่ tunnels และผลิตภัณฑ์ที่แสดงการตั้งค่าอินเทอร์เฟซรับฟังก็ทำงานแบบเดียวกัน คำสั่งรับฟังด้านบนตอบเรื่องนี้โดยตรง

จากนั้นแยกการปฏิเสธออกจากความเงียบ nc -vz 10.6.0.1 443 ที่คืนค่าการเชื่อมต่อถูกปฏิเสธหมายความว่าแพ็กเก็ตไปถึงเราเตอร์และมีบางอย่างปฏิเสธ ไม่ว่าพอร์ตจะปิดหรือมีกฎปฏิเสธชัดเจน การค้างจนหมดเวลาหมายความว่าแพ็กเก็ตถูกทิ้งหรือไม่เคยถูกส่งเส้นทาง ความแตกต่างนี้บอกคุณว่าควรตรวจชั้นใดต่อไป และใช้เวลาห้าวินาที

อินเทอร์เฟซ VPN เป็นขอบเขต ไม่ใช่เส้นทางกู้คืน

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

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

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

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

เตรียมทางกลับก่อนแตะนโยบาย

จดสี่อย่างก่อนการเปลี่ยนแปลงครั้งแรก คุณจะไปถึงอุปกรณ์อย่างไรหากอุโมงค์ตาย เช่น คอนโซลอนุกรม คอนโซลของผู้ให้บริการ หรือเครื่องใน LAN การกำหนดค่าปัจจุบันส่งออกไปที่ใด กฎหรือเส้นทางเดียวใดที่คุณกำลังจะแก้ไข และคุณจะย้อนกลับรายการนั้นอย่างแม่นยำอย่างไร บน OpenWrt sysupgrade -b /tmp/backup.tar.gz เก็บการกำหนดค่า และการแก้ไขจะค้างอยู่จนถึง uci commit ซึ่งให้การย้อนกลับราคาถูกหากคุณสังเกตทัน pfSense เก็บประวัติการกำหนดค่า และ AutoConfigBackup ช่วยเฉพาะเมื่อเปิดใช้อยู่แล้ว หากเราเตอร์ใช้ชุดกฎแบบ fail-closed ให้ยืนยันว่าเส้นทางบำรุงรักษาที่คุณวางแผนไว้ไม่ถูกทราฟฟิกที่กฎนั้นบล็อก และจำไว้ว่าการรีบูตจะใช้กฎถาวรซ้ำแทนการลบ

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

ตรวจเร็ว ๆ ก่อนจากไป

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