Masquerade หรือการกำหนดเส้นทางตามนโยบาย: ทราฟฟิก LAN ผ่านเกตเวย์ VPN

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

การออกแบบทั้งสองสัญญาสิ่งที่แตกต่างกัน

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

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

รูปแบบความล้มเหลวแตกต่างพอ ๆ กับคำสัญญา กฎ masquerade ที่หายไปทำให้แพ็กเก็ตออกไปพร้อมต้นทางส่วนตัวและไม่กลับมาเลย เส้นทางกลับที่หายไปให้อาการเดียวกันในการกำหนดเส้นทางตามนโยบาย แต่การแก้ไขเป็นหน้าที่ของเราเตอร์ฝั่งไกลไม่ใช่เกตเวย์

Masquerade: พีร์เดียวที่ฝั่งไกล

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

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i eth1 -o tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

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

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

การกำหนดเส้นทางตามนโยบาย: เก็บต้นทางไว้ เพิ่มเส้นทางกลับ

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

ip rule add iif eth1 table vpn
ip route add default dev tun0 table vpn

จากนั้นฝั่งไกลต้องกำหนดเส้นทางคำนำหน้า LAN กลับผ่านทันเนล นั่นคือการกำหนดค่าบนเราเตอร์ฝั่งไกล ไม่ใช่บนเกตเวย์นี้ เกตเวย์ยังต้องยอมรับคำตอบที่มาทางอินเทอร์เฟซอื่นจากที่ตารางหลักคาดการณ์ การกรองเส้นทางย้อนกลับแบบหลวม (ตั้งค่า rp_filter เป็น 2) คือการปรับตามปกติเมื่อโหมดเข้มงวดทิ้งแพ็กเก็ตเหล่านั้น

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

ตัดสินจากความเป็นเจ้าของและจากสิ่งที่ฝั่งไกลบันทึก

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

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

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

ตรวจสอบจากไคลเอนต์รายหนึ่ง แล้วจากไคลเอนต์อีกราย

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

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

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