ไคลเอนต์ OpenVPN มองไม่เห็นกันและกัน: subnet หรือ net30?
ไคลเอนต์เข้าถึงเซิร์ฟเวอร์ได้แต่ไม่ถึงกันและกัน แยกความผิดพลาดด้วย ping ครั้งเดียว แล้วเลือกโทโพโลยี subnet, client-to-client หรือส่วน TAP ที่เชื่อมบริดจ์
ความผิดพลาดสองอย่างที่ไม่เกี่ยวข้องกันให้อาการเดียวกัน ในกรณีแรกไคลเอนต์หนึ่งเข้าถึงอีกตัวไม่ได้แม้ด้วยที่อยู่ทันเนล เพราะที่อยู่ไม่ได้อยู่ใน subnet เดียวกันหรือเซิร์ฟเวอร์ไม่ส่งต่อทราฟฟิกระหว่างกัน ในกรณีที่สอง ping ทำงานแต่รายการอุปกรณ์ของแอปยังว่าง เพราะการค้นหาอาศัย broadcast ที่ทันเนลชั้น 3 พาไปไม่ได้ ping ครั้งเดียวแยกสองกรณีนี้ และวิธีแก้ของแต่ละกรณีไม่เหมือนกันเลย
ping ครั้งเดียวแบ่งปัญหาเป็นสอง
จากไคลเอนต์หนึ่ง ping ไปที่ที่อยู่ทันเนลของอีกไคลเอนต์ ไม่ใช่ชื่อและไม่ใช่ที่อยู่ LAN ถ้าล้มเหลว การส่งต่อหรือการกำหนดที่อยู่คือปัญหา และการค้นหาไม่เกี่ยวข้องจนกว่าจะแก้ไข ถ้าสำเร็จ การส่งต่อทำงานอยู่แล้ว และสิ่งที่ขาดคือ broadcast หรือการแปลงชื่อ
ip addr show tun0อ่านอินเทอร์เฟซของไคลเอนต์ก่อนสิ่งอื่นใด เพราะเน็ตมาสก์บอกชื่อโทโพโลยี /24 หรือมาสก์ subnet อื่นหมายถึงพูลที่ใช้ร่วมกัน /30 ที่มีที่อยู่เพียร์หมายถึงรูปแบบจุดต่อจุดเดิม ซึ่งไคลเอนต์แต่ละตัวมีเพื่อนบ้านเพียงหนึ่งเดียวคือเซิร์ฟเวอร์
net30 เทียบกับ subnet มองจากฝั่งไคลเอนต์
| What you observe | net30 | subnet |
|---|---|---|
| Client netmask | /30 with a peer address | The pool's own mask |
| Peers a client can address directly | One, the server | Every client in the pool |
| Addressing | One /30 block per client, with the server as the only peer | One pool mask shared by all clients |
| Effect of client-to-client | Required for any peer traffic | Required for peer traffic, still no broadcast |
ด้วย net30 เซิร์ฟเวอร์แจก บล็อกเล็ก ๆ ให้แต่ละไคลเอนต์ ดังนั้นจึงไม่มีเส้นทางไปยังที่อยู่ทันเนลของไคลเอนต์อื่นเว้นแต่เซิร์ฟเวอร์จะส่งต่อ ด้วย subnet พูลทั้งหมดเป็นเครือข่ายเดียว ไคลเอนต์ทุกตัวเข้าถึงกันได้ และเซิร์ฟเวอร์ส่งต่อระหว่างกัน นี่คือเหตุผลที่การตั้งค่าเซิร์ฟเวอร์ชุดหนึ่งดูปกติได้ขณะที่ ping ระหว่างกันล้มเหลว ไม่มีอะไรเสียหาย ไคลเอนต์เพียงไม่ได้อยู่ในเครือข่ายเดียวกัน ไคลเอนต์เห็นลิงก์ที่ทำงานและที่อยู่เพียร์ที่ไม่ตอบ ซึ่งอ่านเหมือนไฟร์วอลล์แต่จริง ๆ แล้วคือรูปแบบการกำหนดที่อยู่
การเปลี่ยนไดเรกทีฟคือการแก้ไขฝั่งเซิร์ฟเวอร์บวกกับการรีสตาร์ต และมีผลกับการเชื่อมต่อครั้งถัดไปไม่ใช่เซสชันที่เปิดอยู่แล้ว เชื่อมต่อไคลเอนต์ใหม่ก่อนตัดสินการเปลี่ยนแปลง หากอุปกรณ์สร้างการตั้งค่าใหม่จากอินเทอร์เฟซเว็บ ให้บันทึกไดเรกทีฟ ไฟล์ และวันที่ และแก้ไขผ่านอินเทอร์เฟซเมื่อมี เพราะการสร้างใหม่จะเขียนทับการแก้ไขด้วยมือในการบันทึกครั้งถัดไป
client-to-client เป็นประตูแยกต่างหาก
แม้ภายใน subnet เดียว เซิร์ฟเวอร์ทิ้งแพ็กเก็ตที่มาจากไคลเอนต์หนึ่งและส่งถึงอีกตัว เว้นแต่ตั้ง client-to-client คำสำคัญนั้นทำให้เซิร์ฟเวอร์เป็นผู้ส่งต่อทราฟฟิกระหว่างกันแทนที่จะเป็นปลายทางที่รับเท่านั้น นี่คือเงื่อนไขที่สองที่ผู้คนมองข้ามหลังจากแก้โทโพโลยีแล้ว
สิ่งนี้ไม่ครอบคลุมถึง broadcast การตั้งค่านี้ส่งต่อ unicast ระหว่างไคลเอนต์ ไม่ได้ทำให้ทันเนลเป็นเซกเมนต์ร่วม และไม่ว่าจะตั้งมากเพียงใดก็ไม่ส่งคำค้นหาการค้นหาแบบ multicast ไปถึงทุกเพียร์
TUN เทียบกับ TAP และแต่ละอย่างพาอะไรได้
| Property | TUN | TAP |
|---|---|---|
| Layer | Layer 3, IP packets | Layer 2, Ethernet frames |
| Broadcast and multicast | Not carried | Carried |
| Bridging to the LAN | Not applicable | Required for a shared segment |
| Client platform support | Everywhere | Missing on Android and iOS, limited on macOS |
การเชื่อมบริดจ์อุปกรณ์ tap เข้า LAN ทำให้ไคลเอนต์ระยะไกลอยู่ในโดเมน broadcast ของสำนักงาน ซึ่งแก้ปัญหาการค้นหาได้ทั้งหมด ราคาที่ต้องจ่ายคือแพลตฟอร์มที่ไม่รองรับ TAP บริดจ์ที่ต้องมีบนเซิร์ฟเวอร์ และโดเมนความล้มเหลวที่พายุ broadcast บนสายสำนักงานไปถึงแล็ปท็อประยะไกลทุกเครื่อง
สำหรับเวิร์กสเตชันสองหรือสามเครื่องที่ต้องการการแปลงชื่อ รายการ hosts หรือที่อยู่ unicast ถูกกว่าบริดจ์มาก ใช้ TAP เมื่อโปรโตคอลที่แทนที่ไม่ได้ขึ้นกับการค้นหาในชั้น 2 และไม่ใช่ก่อนหน้านั้น
ไคลเอนต์ใน subnet เดียวกันโดยไม่มีบริดจ์
การกำหนดที่อยู่จากช่วง LAN ไม่ได้ทำให้ไคลเอนต์อยู่บนสาย เซิร์ฟเวอร์กำหนดเส้นทางระหว่างทันเนลและอีเทอร์เน็ต ดังนั้น ARP สำหรับที่อยู่นั้นหยุดที่อินเทอร์เฟซของเซิร์ฟเวอร์ และ LAN ที่เหลือไม่มีทางรู้ว่ามันอาศัยอยู่ที่ไหน
ip neigh add proxy 10.50.1.250 dev eth0Proxy ARP ปิดช่องว่างนั้นโดยให้เซิร์ฟเวอร์ตอบแทนไคลเอนต์ สำหรับช่วงหนึ่ง parpd จัดการรายการขณะไคลเอนต์เข้าและออก ขณะที่ sysctl net.ipv4.conf.eth0.proxy_arp=1 ตอบสำหรับทุกสิ่งที่กำหนดเส้นทางไปที่อื่น ซึ่งกว้างพอที่จะสร้างความประหลาดใจของตัวเองบนเซกเมนต์ที่ใช้งานหนัก
ไม่ว่าจะเลือกเส้นทางใด ให้เอา NAT ออกจากระหว่างทันเนลและสาย กฎ MASQUERADE ซ่อนคำถามเรื่องการกำหนดที่อยู่ที่คุณกำลังพยายามตอบพอดี และยังทิ้งโทโพโลยีที่คนถัดไปไม่อาจคิดตามได้จากฝั่งไคลเอนต์
ก่อนเปลี่ยนสิ่งใด ให้จับความพยายามหนึ่งครั้งบนเซิร์ฟเวอร์ด้วย tcpdump -ni tun0 และยืนยันว่าแพ็กเก็ตของเพียร์มาถึงหรือไม่ การมาถึงแล้วถูกทิ้งชี้ไปที่ client-to-client การไม่มาถึงเลยชี้ไปที่โทโพโลยีหรือการกำหนดเส้นทาง คู่มือ OpenVPN 2.6 อธิบายคำสำคัญทั้งสองและโทโพโลยีเริ่มต้น ซึ่งควรนำมาเทียบกับเวอร์ชันของคุณก่อนคัดลอกบรรทัดจากโพสต์ในฟอรัม
- อินเทอร์เฟซ tun แสดงมาสก์ของพูลไม่ใช่คู่เพียร์ /30
- ping ตรงไปยังที่อยู่ทันเนลอีกอันสำเร็จก่อนที่คุณจะทดสอบการค้นหา
- การตั้งค่าเซิร์ฟเวอร์มี
client-to-clientทุกครั้งที่เพียร์ต้องแลกเปลี่ยนแพ็กเก็ต - ระบุชื่อโปรโตคอลการค้นหาที่คุณกำลังทดสอบแทนที่จะบอกว่าแอปล้มเหลว
- ใช้ TAP เฉพาะเมื่อทุกแพลตฟอร์มไคลเอนต์ในกลุ่มรองรับ
- เก็บ NAT ออกจากเส้นทางระหว่างทันเนลและ LAN เมื่อการเข้าถึงภายใน subnet เดียวกันสำคัญ