ใส่ที่อยู่ VPN ในไวต์ลิสต์แล้วยังถูกบล็อกอยู่? ตามรอยดู

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

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

ที่อยู่ในแอปไม่ใช่ที่อยู่ที่มาถึง

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

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

ตามรอยคำขอหนึ่งรายการจนถึงขอบเขตการกรอง

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

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

iptables -vnL INPUT --line-numbers
iptables -S INPUT | head -n 40
ss -ltnp | grep -E ':(443|9443)\b'

อ้างหมายเลขกฎที่ตรงกันในตั๋ว หากไม่มี ผู้อ่านคนถัดไปจะไม่รู้ว่าการแก้ไขใดเปลี่ยนผลลัพธ์ หมายเลขกฎที่ไม่มีเวลาไทยังคงกำกวม

ตรวจสอบเส้นทางด้วยการดักจับหนึ่งครั้งแบบจำกัด

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

tcpdump -ni any 'tcp dst port 9443' -c 20

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

อ่านลำดับของเชน ไม่ใช่แค่กฎ

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

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

เปลี่ยนกฎที่เจ้าของควบคุม

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

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