LAN साठी VirtualBox VPN गेटवे: ब्रिज, मार्ग, परतीचा

दूरस्थ वापरकर्त्यांना भौतिक LAN वरील प्रिंटर आणि फाइल सर्व्हरपर्यंत पोहोचायचे असते, आणि सतत सुरू असलेला एकमेव Linux बॉक्स म्हणजे VirtualBox VM। त्या VM ला त्या LAN वर ब्रिज करणे हा पहिला अर्धा भाग आहे। दुसरा अर्धा भाग म्हणजे परतीचा मार्ग जो LAN वरील प्रत्येक उपकरण खरोखर वापरेल, आणि बहुतेक सेटअप जिथे चुकतात तोच भाग। तो नसेल तर टनेल जोडले जाते, क्लायंट गेटवेला पिंग करतो, आणि दुसरे काहीही उत्तर देत नाही।

पोहोचता येतील असे पत्ते वापरा

VM चा LAN अडॅप्टर त्या नेटवर्कसाठी मंजूर Bridged Adapter मोडवर ठेवा, आणि नेहमीच्या वाटप प्रक्रियेतून त्याला पत्ता द्या। मग VM भौतिक LAN वर इतर कोणत्याही होस्टसारखे दिसते। तिचा डीफॉल्ट मार्ग अजूनही खऱ्या गेटवेचा वापर करायला हवा, जेणेकरून VPN पीअरपर्यंतची एन्क्रिप्टेड वाहतूक पोहोचण्यायोग्य राहील। VirtualBox चा डीफॉल्ट NAT पत्ता LAN चा पुढील हॉप म्हणून वापरू नका, कारण तो पत्ता व्हर्च्युअल NAT च्या मागे असतो आणि होस्ट किंवा LAN वरील इतर मशीनसाठी on-link नाही।

LAN router:          192.168.70.1/24
VirtualBox host:     192.168.70.5/24
VPN gateway VM:      192.168.70.10/24
Example LAN service: 192.168.70.40
VPN client pool:     10.80.0.0/24

पूल निवडण्यापूर्वी दूरस्थ वापरकर्त्यांच्या घरगुती नेटवर्कशी ओव्हरलॅप आहे का ते तपासा। ओव्हरलॅप हा राउटिंगचा असा संदिग्धपणा बनतो जो कोणताही सर्व्हर कॉन्फिगरेशन दुरुस्त करू शकत नाही।

LAN ची घोषणा करा, मग फॉरवर्ड करा

ज्या सर्व्हरचे प्रमाणीकरण आणि वाहतूक आधीच व्यवस्थापित केले जाते, त्यासाठी नेटवर्किंग ओळी अशा दिसतात। push स्वीकारणाऱ्या क्लायंटला LAN पर्यंत कसे पोहोचायचे ते सांगतो, आणि ते स्वतः VM ला काहीही फॉरवर्ड करायला भाग पाडत नाही।

dev tun
topology subnet
server 10.80.0.0 255.255.255.0
push "route 192.168.70.0 255.255.255.0"

VM च्या कायमस्वरूपी नेटवर्क कॉन्फिगरेशनमध्ये IPv4 फॉरवर्डिंग सुरू करा, आणि क्लायंट पूलला VM च्या फॉरवर्डिंग सीमेवर इच्छित LAN सेवांपर्यंत पोहोचण्याची परवानगी द्या। VPN श्रोत्यापर्यंत पोहोचण्याची परवानगी हा वेगळा नियम आहे, आणि टनेल वर आली असेल तर तो आधीच काम करत आहे।

परतीचा मार्ग LAN राउटरवर असतो

LAN वरील उपकरणे त्यांच्या डीफॉल्ट गेटवेमधून उत्तर देतात, जो 192.168.70.1 वरचा LAN राउटर आहे। सांगितल्याशिवाय त्या राउटरला 10.80.0.0/24 कुठे आहे हे माहीत नसते। पूलचा मार्ग राउटरच्या समर्थित कायमस्वरूपी कॉन्फिगरेशनमध्ये जोडा, तो VM च्या LAN पत्त्याकडे निर्देश करतो। तो फक्त VirtualBox होस्टवर जोडल्यास त्या होस्टला विचारणाऱ्या वाटाच दुरुस्त होतात, आणि तो LAN वरील प्रत्येक उपकरण नाही।

ip route add 10.80.0.0/24 via 192.168.70.10

गंतव्यस्थानाच्या स्वतःच्या फायरवॉलला अजूनही क्लायंट पूलला स्रोत म्हणून परवानगी द्यावी लागते। मार्ग पॅकेट वाहून नेतो; तो सेवा देत नाही।

LAN राउटर बदलता येत नसेल, तर VM वर मर्यादित स्रोत भाषांतर हा पर्याय आहे। ते मार्गाशिवाय उत्तरे परत आणते, आणि LAN सेवेपासून वैयक्तिक क्लायंट पत्ते लपवते।

एक पॅकेट सुरुवातीपासून शेवटपर्यंत पाहा

10.80.0.25 वरचा क्लायंट टनेलमधून 192.168.70.40 वर पाठवतो। VM पॅकेट LAN वर फॉरवर्ड करते। सेवा तिच्या राउटरला उत्तर देते, जो क्लायंट पूलसाठी VM निवडतो, आणि VM पॅकेट OpenVPN मधून परत पाठवते। त्या वाक्यातील प्रत्येक हॉप ही अशी जागा आहे जिथे रचना अयशस्वी होऊ शकते।

दूरस्थ क्लायंटवरून खऱ्या अनुप्रयोगासह चाचणी करा, मग VM आणि राउटर दोन्हीवर व्यवस्थापित कॉन्फिगरेशन पुन्हा लोड केल्यानंतर पुन्हा करा।

क्लायंट VM पर्यंत पोहोचतो पण सेवेपर्यंत पोहोचत नसेल, तर आधी राउटरचा मार्ग तपासा। सेवा विनंती स्वीकारते आणि क्लायंटला उत्तर कधीच दिसत नसेल, तर संशयास्पद परतीचा मार्गच आहे।