เว็บไซต์ NGINX สำหรับ VPN เท่านั้น: ตัวรับฟัง ไฟร์วอลล์ และรายการอนุญาต HTTP

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

ตัวอย่างใช้เกตเวย์ Linux OpenVPN ที่ 10.90.0.1 บน tun0 ไคลเอนต์ใน 10.90.0.0/24 แหล่งที่มาที่คงไว้ และ TCP 8443 ที่สงวนไว้สำหรับทางเข้านี้ ปรับค่าและคงชั้นไว้

เริ่มจากซ็อกเก็ต ไม่ใช่ชื่อโฮสต์

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

server {
    listen 10.90.0.1:8443 ssl;
    server_name admin.corp.example;

    ssl_certificate     /etc/nginx/tls/admin-fullchain.pem;
    ssl_certificate_key /etc/nginx/tls/admin-key.pem;

    root /srv/private-site;

    allow 10.90.0.0/24;
    deny all;

    location / {
        try_files $uri $uri/ =404;
    }
}

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

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

ปิดตัวรับฟังอื่นทั้งหมดสำหรับเนื้อหานั้น

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

sudo nginx -T | grep -n "listen\|server_name\|root\|proxy_pass"

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

ปลดระวางโฮสต์เสมือนเก่าเป็นการเปลี่ยนแปลงแยกต่างหาก การลบแฝดสาธารณะของบล็อกใหม่มักเป็นขั้นตอนที่ปิดทางเข้าได้จริง ตัวรับฟังส่วนตัวเพียงเพิ่มทางเข้าที่ตั้งใจไว้

จำกัดขอบเขตเส้นทางขาเข้าที่โฮสต์

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

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

sudo ufw allow in on tun0 proto tcp from 10.90.0.0/24 to 10.90.0.1 port 8443

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

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

รักษารายการ HTTP ให้สมบูรณ์เมื่อตำแหน่งเปลี่ยน

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

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

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

การปฏิเสธ HTTP เกิดขึ้นหลังการเชื่อมต่อ TCP มาถึง NGINX มันเสริมข้อจำกัดเครือข่าย และการอนุญาตของแอปพลิเคชันเองยังใช้กับผู้ใช้แต่ละราย

ตรวจสอบเส้นทางจริงและกรณีล้มเหลว

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

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

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

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