pfSense เป็นทั้งเซิร์ฟเวอร์และไคลเอนต์ VPN: สองเส้นทาง เราเตอร์เดียว

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

ตั้งชื่อสองบทบาทก่อนแตะการตั้งค่าใด ๆ

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

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

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

เก็บคำตอบของเซิร์ฟเวอร์ไว้บนเส้นทาง WAN

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

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

netstat -rn | head -20
pfctl -sr | grep -i vpn
ifconfig | grep -A3 ovpn

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

อย่าให้อุโมงค์ขาออกกินปลายทางของตัวเอง

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

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

netstat -rn | grep -F '198.51.100.10'
traceroute -n 198.51.100.10

เลือกว่าผู้ใช้คนใดจะได้ทางออก

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

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

openvpn --config user07.ovpn
curl -sS https://ifconfig.me
curl --interface 10.10.10.1 -sS https://intranet.corp.example/health

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

ตัดสินใจว่าเกิดอะไรขึ้นเมื่อทางออกล้มเหลว

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

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

pfSsh.php playback svc stop openvpn client 2
curl --max-time 6 -sS https://ifconfig.me
pfSsh.php playback svc start openvpn client 2

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