เส้นทาง VPN หรือกฎไฟร์วอลล์: อะไรกำลังทิ้งแพ็กเก็ต?

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

สองการตัดสินใจ หนึ่งแพ็กเก็ต สองเจ้าของ

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

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

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

อ่านว่าการค้นหาเลือกอะไรจริง ๆ

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

ip route get 10.8.0.5
ip route get 10.8.0.5 from 192.0.2.44
ip rule show
ip route show table all | sed -n '1,40p'

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

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

การกรองมีผลที่ตะขอ ไม่ใช่ที่เส้นทาง

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

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

ส่งโพรบผ่านเส้นทางที่ไคลเอนต์ใช้

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

nc -vz -w 3 10.8.0.5 443
ping -c 3 -W 1 10.8.0.5
tcpdump -ni any host 10.8.0.5 and port 443
iptables -vnL FORWARD --line-numbers
nft list ruleset | sed -n '1,60p'

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

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

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

วางการเปลี่ยนแปลงแต่ละอย่างไว้ในที่ที่อยู่รอดหลังการเชื่อมต่อใหม่

เส้นทางที่เพิ่มด้วย ip route add อยู่จนกว่าอินเทอร์เฟซจะล่ม บันทึกไว้ในโปรไฟล์การเชื่อมต่อแทน: NetworkManager ยอมรับเส้นทางเพิ่มเติมบนการเชื่อมต่อ และ netplan เก็บไว้ข้ามการบูต กฎเดียวกันใช้กับการยกเว้นไฟร์วอลล์ฝั่งไคลเอนต์ ซึ่งหายไปหลังการโหลดใหม่ครั้งถัดไป

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

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