VPN เชื่อมต่อแล้วแต่ไฟร์วอลล์ยังบล็อก: จะรู้ได้อย่างไรว่าฝั่งไหน

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

แยกเส้นทางออกจากนโยบาย

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

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

อ่านเส้นทางในครั้งเดียว

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

ip route get 10.20.4.15
ip -brief address show
wg show
sudo ipsec statusall

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

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

อ่านนโยบายในชั้นที่เป็นผู้ตอบ

เมื่อเส้นทางถูกต้อง ให้ไล่นโยบายจากโฮสต์ออกไปด้านนอกและสังเกตชั้นเดียวที่ตัวนับขยับ:

ss -ltn | grep ':443'
sudo nft list ruleset
sudo iptables -S INPUT
sudo ufw status verbose

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

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

อ่านการตัดสินใจของเกตเวย์เมื่ออุโมงค์สิ้นสุดที่นั่น

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

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

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

เปลี่ยนชั้นที่แคบที่สุด แล้วตรวจสอบ

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

ตรวจสอบด้วยการทดสอบเดิมที่ล้มเหลว จากไคลเอนต์เดิม และอีกครั้งหลังเชื่อมต่อใหม่ เพราะกฎที่ตรงก่อนที่อุโมงค์จะเจรจาใหม่อาจเลิกตรงหลังจากนั้น:

nc -vz 10.20.4.15 443
curl -v --max-time 5 https://10.20.4.15/

ก่อนปิด:

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