ไฟร์วอลล์บนคลาวด์เทียบกับไฟร์วอลล์บนโฮสต์สำหรับเซิร์ฟเวอร์ VPN

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

เริ่มที่ขอบแล้วเดินเข้าไปข้างใน

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

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

อ่านนโยบายคลาวด์ก่อนแตะเกสต์

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

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

ยืนยันตัวรับฟัง แล้วจึงตรวจสอบเชนอินพุต

บนอินสแตนซ์ ตรวจสอบว่าโปรเซส VPN ผูกกับที่อยู่และพอร์ตที่คุณคาดไว้หรือไม่ เช่นด้วย ss -lntp 'sport = :1194' เดมอนที่ผูกกับ 127.0.0.1 เท่านั้นจะรับไคลเอนต์ภายในเครื่องและไม่รับอะไรผ่านอุโมงค์ ซึ่งมองจากภายนอกดูเหมือนพอร์ตที่ถูกกรองทุกประการ

จากนั้นอ่านกฎภายในเครื่องด้วยไวยากรณ์ที่คุณจะใช้แก้ไข เช่น iptables -S INPUT หรือ nft list chain inet filter input กฎที่เขียนลงไฟล์แต่ไม่เคยโหลด หรือการทิ้งค่าเริ่มต้นโดยไม่มีการอนุญาตที่ตรงกัน จะทิ้งแพ็กเก็ตอย่างเงียบ ๆ สำหรับเกตเวย์ที่ส่งต่อ ให้ตรวจสอบการตั้งค่าการส่งต่อและเส้นทางย้อนกลับด้วย สิ่งเหล่านี้เป็นตัวกำหนดว่าเกิดอะไรขึ้นกับแพ็กเก็ตที่ถูกกำหนดเส้นทางผ่านอินสแตนซ์ ไม่ใช่ที่ส่งถึงอินสแตนซ์

มีสถานะในชั้นหนึ่ง ไม่มีสถานะในชั้นถัดไป

กลุ่มความปลอดภัยจดจำโฟลว์ที่อนุญาตและปล่อยให้คำตอบกลับเข้ามา รายการควบคุมการเข้าถึงของซับเน็ตและไฟร์วอลล์บนโฮสต์หลายตัวไม่เก็บสถานะเช่นนั้น กฎที่ครอบคลุมเพียงทิศทางออกจึงปล่อยคำขอผ่านและทิ้งคำตอบ อย่าพาสมมติฐานเรื่องทราฟฟิกตอบกลับข้ามชั้นโดยไม่อ่านกฎของชั้นที่สอง (second layer's rule)

ตัวนับตัดสินเรื่องนี้ได้เร็วกว่าการอ่านทุกกฎในบัญชี ตัวนับที่เพิ่มขึ้นหมายความว่าแพ็กเก็ตมาถึงและถูกทิ้งที่นั่น ส่วนตัวที่หยุดนิ่งที่ศูนย์หมายความว่ามันไปไม่ถึงที่นั่นเลย iptables -vnL INPUT และ nft list ruleset จะแสดงตัวเลขเหล่านั้นเมื่อโหลดกฎพร้อมตัวนับ

ทดสอบด้วยเซสชันใหม่ ไม่ใช่เซสชันที่เปิดอยู่

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

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