NAT ที่เซิร์ฟเวอร์ VPN หรือที่เราเตอร์? ทั้งสองแบบใช้ได้

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

ความเชื่อผิด: เส้นทางของไคลเอนต์สร้างทางออก

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

ความไม่ตรงกันนั้นคือปัญหาทั้งหมดที่ส่วนที่เหลือของบทความนี้แก้ สิ่งหนึ่งต้องทำให้ที่อยู่ส่วนตัวของไคลเอนต์ส่งกลับได้ และทางเลือกคือที่ไหน

วาดเส้นทางขากลับก่อน

เขียนเส้นทางด้วยที่อยู่จริงก่อนแตะการตั้งค่าใด ๆ และทำเครื่องหมายจุดแปลที่เป็นไปได้สองจุดบนเส้นทางนั้น แล็บนี้ใช้พูล VPN 10.70.0.0/24 โดยมีไคลเอนต์หนึ่งเครื่องที่ 10.70.0.37 ที่อยู่ LAN ของเซิร์ฟเวอร์ 172.16.40.10 เราเตอร์ที่ 172.16.40.1 และทางออกสาธารณะ 203.0.113.40

client 10.70.0.37 -- tunnel --> RRAS 172.16.40.10 -- LAN --> router 172.16.40.1 --> 203.0.113.40
                                  (translate here?)                             (or here?)

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

ตัวเลือก A: แปลที่เซิร์ฟเวอร์ VPN

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

Get-RemoteAccess | Select-Object VpnS2SInterface, RoutingDomain
Get-NetNat | Select-Object Name, InternalIPInterfaceAddressPrefix

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

ตัวเลือก B: ย้ายพูลไปที่เราเตอร์

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

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

ทำให้ DNS, IPv6 และการยอมรับชัดเจน

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

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

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