เกตเวย์โฮสต์หน้าผู้ดูแลระบบของตัวเอง: ที่อยู่ภายในหรือสาธารณะ

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

หน้าเว็บโหลดจากภายนอก ไม่ใช่ผ่านอุโมงค์

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

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

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

รักษาปลายทางภายนอกให้เข้าถึงได้

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

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

อ่านการตัดสินใจของเส้นทาง ไม่ใช่รายการอินเทอร์เฟซ ก่อนเปลี่ยนสิ่งใด คำสั่งด้านล่างพิมพ์การตัดสินใจ ไม่ใช่บัญชีทรัพย์สิน รันจากไคลเอนต์ที่ล้มเหลว

ip -4 route get 203.0.113.77
ip -4 rule show
ip -4 route show table all

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

ให้ชื่อส่วนตัวแก่บริการ

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

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

ตรวจสอบตระกูลที่อยู่ทั้งสองด้วย เพราะระเบียน AAAA ที่หลงเหลืออาจส่งเบราว์เซอร์ไปที่ที่แผนส่วนตัวไม่เคยครอบคลุม

dig +short admin.hq.internal
dig +short -t AAAA admin.hq.internal
curl -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://admin.hq.internal/

ปรับนโยบายให้ตรงกับที่โปรเซสทำงาน

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

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

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

ตรวจสอบการเข้าถึงส่วนตัวและเส้นทางสาธารณะที่ถูกปฏิเสธ

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

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

ss -lntp | grep ':443'
nft list ruleset | grep -n 443
curl -sS -m 5 -o /dev/null -w '%{http_code}\n' https://203.0.113.77/

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