Pi เดียว สองอินสแตนซ์ OpenVPN: แต่ละยูนิตอ่านอะไร
เดมอน OpenVPN สองตัวบน Pi เดียวอ่านไฟล์กำหนดค่าคนละไฟล์และออกผ่านฮุกคนละจุด จับคู่แต่ละอินสแตนซ์ แล้วทดสอบเส้นทางเพย์โหลดแยกกัน
นับโปรเซส OpenVPN ก่อนแตะโปรไฟล์ Pi ที่รับผู้ใช้แบบ roaming และเชื่อมต่อไปยังบริการต้นทางด้วยจะรันเดมอนสองตัว และแต่ละตัวอ่านไฟล์กำหนดค่าที่เลือกโดยชื่ออินสแตนซ์ที่คุณพิมพ์ แม่แบบของแพ็กเกจจะมอบไดเรกทอรีทำงาน ไฟล์สถานะขณะรัน และอุปกรณ์อุโมงค์ให้แต่ละเดมอนแยกกัน ถ้าแบ่งผิด คุณจะเสียเวลาทั้งเย็นแก้ค่าที่ถูกต้องในไฟล์ที่โปรเซสที่กำลังรันไม่เคยเปิด
ชื่ออินสแตนซ์แต่ละชื่อเลือกไฟล์ของตัวเอง
ในไฟล์ยูนิตที่มาพร้อม OpenVPN 2.6 อาร์กิวเมนต์เริ่มต้นมีตัวแทนอินสแตนซ์ที่เติมจากข้อความหลังเครื่องหมาย @ แม่แบบเซิร์ฟเวอร์รันจากไดเรกทอรีกำหนดค่าของเซิร์ฟเวอร์และแปลงอาร์กิวเมนต์กับ %i.conf ที่นั่น ส่วนแม่แบบไคลเอนต์ทำเช่นเดียวกันจากไดเรกทอรีไคลเอนต์ ดังนั้น [email protected] อ่าน admits.conf ในไดเรกทอรีเซิร์ฟเวอร์ และ [email protected] อ่าน uplink.conf ในไดเรกทอรีไคลเอนต์ และชื่อเหล่านี้ไม่มีความหมายใด ๆ ในอีกไดเรกทอรีหนึ่ง
ยืนยันการจับคู่บนเครื่องแทนที่จะสมมติว่าแพ็กเกจคงค่าเริ่มต้นต้นทางไว้ drop-in ของดิสทริบิวชันสามารถแทนที่ไดเรกทอรีทำงานหรืออาร์กิวเมนต์กำหนดค่าได้ทั้งหมด
systemctl cat [email protected]
systemctl cat [email protected]อ่านบรรทัด WorkingDirectory และอาร์กิวเมนต์กำหนดค่าในเอาต์พุตนั้น เพราะยูนิตที่เปิดใช้งานเท่านั้นที่ตัดสินว่าโหลดไฟล์ใด drop-in ที่เพิ่ม --config ต่อท้าย ExecStart ชนะแม่แบบแม้เส้นทางของแม่แบบดูถูกต้อง ขอเส้นทางของ fragment และ drop-in เมื่อต้องการรู้ว่ามีการแทนที่ในเครื่องหรือไม่ ถ้าทั้งสองบทบาทแปลงเป็นไฟล์เดียว คุณมีโปรเซสเดียวที่พยายามเป็นทั้งเซิร์ฟเวอร์และไคลเอนต์ และตัวเลือกที่อยู่ท้ายไฟล์นั้นชนะอย่างเงียบ ๆ
การขนส่งในเครื่องและเพย์โหลดที่ส่งต่อชนฮุกคนละจุด
การเชื่อมต่อที่เข้ารหัสของเซิร์ฟเวอร์กับผู้ใช้ roaming แต่ละรายถูกสร้างบน Pi เอง ดังนั้นการตอบกลับภายนอกจึงออกผ่านฮุกเอาต์พุตในเครื่อง การเชื่อมต่อของไคลเอนต์กับคู่ค้าต้นทางก็เป็นเอาต์พุตที่สร้างในเครื่องเช่นกัน แม้จะไปถึงเครือข่ายระยะไกล เพย์โหลดที่ส่งต่อเป็นหมวดที่สาม และเคอร์เนลจะจับคู่ก็ต่อเมื่อเลือกอุปกรณ์ขาออกให้แพ็กเก็ตแล้วเท่านั้น
| Flow | Hook that sees it | What to inspect |
|---|---|---|
| Roaming user handshakes to the server | Local input and local output | Listener socket, bind address, rule admitting the UDP port |
| User payload leaving through the upstream tunnel | Forward | IPv4 forwarding switch, selected route, permission rule, any translation |
| Pi's own connection to the upstream peer | Local output | Underlay route to the provider endpoint, not the tunnel route |
กฎที่ตรงกับอินเทอร์เฟซขาออกในเชน forward สามารถอนุญาตหรือทิ้งแพ็กเก็ตที่เราเตอร์ได้กำหนดให้อินเทอร์เฟซนั้นแล้ว แต่ไม่เคยเลือกอินเทอร์เฟซ เมื่อโฮสต์หนึ่งสิ้นสุดอุโมงค์หนึ่งและเริ่มอีกอันหนึ่ง นโยบายที่ส่งเพย์โหลดผู้ใช้เข้าอุโมงค์ต้นทางและนโยบายที่ปกป้องการตอบกลับที่เข้ารหัสของ Pi เองเป็นการตัดสินใจสองอย่างแยกกัน ทั้งสองบังเอิญลงเอยบน NIC กายภาพเดียวกัน จึงทำให้สับสน
ความแตกต่างนั้นอธิบายความล้มเหลวครึ่งเดียวที่พบได้บ่อย ผู้ใช้เชื่อมต่อ handshake สำเร็จ แต่ทราฟฟิกยังออกผิดทาง เพราะ handshake เป็นแบบในเครื่องและเพย์โหลดเป็น forward และมีการทดสอบเพียงหนึ่งในสองอย่างเท่านั้น
เส้นทางที่นำเข้าอาจกลืนการตอบกลับถึงผู้ใช้ของคุณ
การตั้งค่าความปลอดภัยของโปรไฟล์ไคลเอนต์กำหนดว่าต้นทางสามารถดันอะไรเข้าตารางเส้นทางของ Pi ได้ และการเปลี่ยนเส้นทางแบบกว้างคือตัวเลือกที่ทำให้โฮสต์สองบทบาทที่ทำงานอยู่กลายเป็นพัง หากเส้นทางที่ดันครอบคลุมที่อยู่สาธารณะของผู้ใช้ roaming การตอบกลับที่เซิร์ฟเวอร์สร้างขึ้นถึงพวกเขาอาจตามเส้นทางใหม่เข้าอุโมงค์ต้นทางแทนที่จะออกผ่าน underlay ผู้คนมักยืนยันว่าอุโมงค์ไปยังผู้ให้บริการยังทำงานแล้วหยุดอยู่แค่นั้น เพราะทราฟฟิกนั้นคือการขนส่งของอุโมงค์เองและยังคงไหลอยู่ขณะที่อย่างอื่นทำงานผิด
นโยบายตามต้นทางหรือ mark คือวิธีที่ทำให้สองสตรีมแยกจากกัน ตัวเลือก mark ของ Linux ใน OpenVPN ประทับ mark ไฟร์วอลล์บนแพ็กเก็ตที่เข้ารหัสของเดมอนเอง ซึ่งกฎเส้นทางสามารถส่งไปยังตารางเฉพาะได้ ที่อยู่ต้นทางก็ได้ผลเช่นกันเมื่อการตอบกลับภายนอกของเซิร์ฟเวอร์ออกจากที่อยู่ underlay เดียวเสมอ ไม่ว่าแนวทางใดต้องมีเส้นทางที่ถูกต้องในตารางที่เลือกและข้อยกเว้นสำหรับ endpoint ของผู้ให้บริการ มิฉะนั้นอุโมงค์เองจะไม่ขึ้น
ถามเคอร์เนลว่าเส้นทางที่การตอบกลับจะใช้จริงคืออะไรก่อนเขียนกฎใด ๆ ที่อยู่ด้านล่างเป็นตัวแทนของที่อยู่ underlay ของ Pi และที่อยู่สาธารณะของผู้ใช้ roaming หนึ่งราย
ip rule show
ip route get 198.51.100.7 from 192.0.2.10ตรวจสอบการแยก แล้วหยุดทีละบทบาท
ทดสอบสามโฟลว์แยกกัน เพราะ handshake ที่สำเร็จไม่ได้พิสูจน์อะไรเกี่ยวกับอีกสองโฟลว์ ยอมรับการเชื่อมต่อขาเข้าใหม่ ส่งแอปพลิเคชันที่ได้รับอนุญาตหนึ่งตัวผ่านทางออกต้นทาง และยืนยันว่าโปรเซสทั้งสองยังเข้าถึงคู่ของตนได้
จากนั้นหยุดบทบาทไคลเอนต์และดูว่าบทบาทเซิร์ฟเวอร์ยังคงอะไรไว้ นี่เป็นวิธีที่ถูกที่สุดในการหากฎเส้นทางหรือ mark ที่ตั้งใจไว้สำหรับอินสแตนซ์หนึ่งแต่ถูกใช้กับทั้งสอง
systemctl stop [email protected]
systemctl status [email protected] --no-pager
ss -lunp | grep openvpn
journalctl -u [email protected] -n 20 --no-pagerสิ่งที่คุณอยากเห็นคือ listener ยังผูกอยู่ อุปกรณ์อุโมงค์ยังอยู่ และล็อกไม่มีข้อผิดพลาดใหม่ขณะบทบาทไคลเอนต์หยุดทำงาน หากการหยุดไคลเอนต์ตัดการตอบกลับของเซิร์ฟเวอร์ถึงผู้ใช้ที่มีอยู่ด้วย ทั้งสองบทบาทแชร์บางอย่างที่ควรจำกัดไว้เพียงบทบาทเดียว บันทึกว่าการเปลี่ยนแปลงแต่ละครั้งแตะอินสแตนซ์ใด ไฟล์กำหนดค่าใด และเจ้าของโฟลว์ใด เพราะคนถัดไปที่ดีบักโฮสต์นี้จะค้นพบเรื่องเดิมซ้ำตั้งแต่ต้น