การเปิดพอร์ต VPN ไม่ทำให้ไคลเอนต์เข้าถึง LAN ได้

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

สองเชน สองปลายทางที่ต่างกัน

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

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

กฎของผู้ฟังอนุญาตอะไรจริง ๆ

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

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

ทดสอบจากไคลเอนต์ ไม่ใช่จากเกตเวย์

การทดสอบที่สร้างบนเกตเวย์เดินตามเส้นทางขาออกของโฮสต์เองและอาจผ่านได้ขณะที่เส้นทางส่งต่อปิดอยู่ เริ่มทดสอบจากไคลเอนต์และดูปลายทั้งสองของกระแส

nc -vz 10.40.7.25 445
tcpdump -ni tun0 host 10.40.7.25

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

การส่งต่อต้องมีสามอย่าง ไม่ใช่หนึ่ง

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

sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
sudo iptables -S INPUT

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

แยกชุดกฎสองชุดในเอกสาร

เขียนกฎของผู้ฟังและกฎของบริการที่ส่งต่อในบรรทัดแยกกัน พร้อมเจ้าของและเหตุผลแยกกัน เมื่อพอร์ต VPN เปลี่ยนหรือมีบริการใหม่เผยแพร่ การแยกนั้นป้องกันการเปลี่ยนแปลงหนึ่งขยายอีกอย่างเงียบ ๆ

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

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