เบราว์เซอร์สาขาถึงพร็อกซี: สองการเชื่อมต่อ สองเส้นทาง

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

ขั้นตอนที่ 1: เขียนโฟลว์ทั้งสองลงไป

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

branch browser -> site VPN -> central proxy listener
central proxy -> approved egress policy -> website

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

ขั้นตอนที่ 2: ให้เส้นทางแก่เบราว์เซอร์ไปยังตัวรับฟัง

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

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

ขั้นตอนที่ 3: กำหนดค่าเบราว์เซอร์ ไม่ใช่แค่ตารางเส้นทาง

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

บันทึกว่าแอปพลิเคชันใดเคารพการตั้งค่า ไคลเอนต์อีเมล ตัวอัปเดต และเกมมักไม่เคารพ และจะใช้เส้นทางธรรมดาต่อไป

ขั้นตอนที่ 4: พิสูจน์การเชื่อมต่อขาออกของพร็อกซี

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

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

ขั้นตอนที่ 5: แยกความล้มเหลวสี่แบบ

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

รายงานพรมแดนที่คุณสังเกต ไม่ใช่สรุปว่า VPN ล้มเหลว

ขั้นตอนที่ 6: กำหนดขอบเขตและวางแผนทางเลือก

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

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