Firebox ปฏิเสธตามตำแหน่งทางภูมิศาสตร์: หาระยะขั้นตอนการเข้าของ VPN ก่อน

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

การตรวจ 1: ระบุชื่อบริการขาเข้า

สำหรับ Mobile VPN ที่ใช้ SSL, Access Portal และ BOVPN บน TLS ขาเข้าคือ WatchGuard SSLVPN policy. ใช้ข้อจำกัดที่ตั้งใจไว้ตรงนั้น บนบริการที่กำหนดค่าไว้จริง แทนที่จะอนุมานจากกฎการเข้าถึงของผู้ใช้ที่ทำงานภายหลัง.

IPsec ใช้เส้นทางที่ต่างออกไป. นโยบาย IPSec ที่มีมาในตัวอนุญาตให้ทราฟฟิก IPsec ภายนอกเข้าสู่ Firebox สำหรับบริการ branch และ VPN มือถือที่เกี่ยวข้อง และมีลำดับความสำคัญเหนือกว่านโยบาย IPSec ที่สร้างด้วยมือ. หากไคลเอนต์ของคุณเป็น IKEv2 คุณอยู่ในเส้นทางที่สองนั้น และนโยบาย SSLVPN ไม่เกี่ยวข้อง.

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

การตรวจ 2: อ่านการปฏิเสธ ไม่ใช่อ่านทฤษฎี

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

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

การตรวจ 3: นโยบายที่มีในตัวยังเป็นเจ้าของอยู่หรือไม่

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

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

การตรวจ 4: วางแผนการแทนที่ก่อนปิดใช้งาน

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

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

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

การตรวจ 5: แยกตัวตนออกจากตำแหน่งที่ตั้ง

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

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

การตรวจ 6: บันทึกไว้และตรวจสอบทั้งสองเส้นทาง

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

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