URL เดียวสำหรับออฟฟิศและ VPN? ทำไมตำนานบัญชีอนุญาตจึงล้มเหลว

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

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

ตำนาน: การเชื่อมต่อไม่ใช่การกำหนดเส้นทาง

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

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

สถานะคำขอสามแบบ ทางออกที่ได้รับอนุมัติสองทาง

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

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

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

อ่านแหล่งที่มาในจุดที่มีการตัดสินใจ

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

server {
    listen 443 ssl;
    server_name intranet.example.com;

    set_real_ip_from 10.20.0.10;
    real_ip_header X-Forwarded-For;
    real_ip_recursive on;

    location /app/ {
        allow 203.0.113.24;    # office public exit
        allow 198.51.100.77;   # approved VPN egress
        deny  all;
        proxy_pass http://app_backend;
    }
}

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

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

อุโมงค์แบบแยกส่วน: คำขอที่ไม่เคยเข้า

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

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

พิสูจน์การปฏิเสธ แล้วพิสูจน์การกู้คืน

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

curl -sS -o /dev/null -w 'status=%{http_code}
' https://intranet.example.com/app/login
# repeat with the tunnel up, then with it down
tail -f /var/log/nginx/access.log | grep ' /app/'

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

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