VPN હોસ્ટ પર કે VM ની અંદર ચલાવવું? નિર્ણય માર્ગદર્શિકા
ટનલનો માલિક નક્કી કરે છે કે શું શું આવરે છે. હોસ્ટ કે ગેસ્ટ સ્થાન પસંદ કરો, પછી ગેસ્ટની અંદર રૂટ, DNS અને એક્ઝિટ તપાસથી તેની પુષ્ટિ કરો.
ગેસ્ટની અંદર ટનલ બનાવવી અને હોસ્ટ પર તે બનાવવી—બંને બ્રાઉઝર જે સરનામું જણાવે છે તે બદલે છે, અને સામ્ય ત્યાં જ પૂરું થાય છે. ગેસ્ટની માલિકીની ટનલ તેની ચાવીઓ, તેનો ડિફોલ્ટ રૂટ અને તેનું રિઝોલ્વર ગેસ્ટ કર્નલની અંદર રાખે છે, જ્યારે હોસ્ટ એન્ક્રિપ્ટ થયેલા પેકેટ એક દૂરના સરનામે મોકલે છે. હોસ્ટની માલિકીની ટનલ તેનું ઉલટું ચિત્ર છે: હોસ્ટ ક્લાયન્ટ સેશન રાખે છે અને રૂટ તથા નીતિ લાગુ કરે છે, અને ગેસ્ટ બહાર આવે તે ઉધાર લે છે. ખોટો માલિક પસંદ કરો તો પછીનું દરેક લક્ષણ તમને ખોટા મશીન પર મોકલશે. બે આદેશો આ પ્રશ્ન લગભગ એક મિનિટમાં નક્કી કરે છે, અને આ માર્ગદર્શિકાનો બાકીનો ભાગ એ છે કે જવાબ સાથે શું કરવું.
ક્લાયન્ટને અડવા પહેલાં માલિક નક્કી કરો
નિયમ એ વિશે છે કે સાઇફરટેક્સ્ટ ક્યાં બને છે, એ વિશે નહીં કે કયું મશીન VPN આઇકન દેખાડે છે. જો ગેસ્ટ તેને બનાવે, તો ગેસ્ટને VPN સર્વર સુધી કાર્યકારી રૂટ જોઈએ અને હોસ્ટથી બીજું કંઈ નહીં. જો હોસ્ટ તેને બનાવે, તો હોસ્ટ ક્લાયન્ટ સ્થાનિક ટ્રાફિક પર જે નીતિ લાદે તે છતાં ગેસ્ટનો હોસ્ટ-માર્ગ ટકવો જોઈએ.
સામાન્ય રીતે ત્રણ પ્રશ્નો તમારા માટે સ્થાન પસંદ કરે છે. શું ગેસ્ટનાં ટ્રાફિકને હોસ્ટ પરના કોર્પોરેટ ક્લાયન્ટમાંથી પસાર થવું પડશે? તો ટનલ ગેસ્ટની અંદર છે. શું ઘણા ગેસ્ટને એક ક્રેડેન્શિયલ અને એક એક્ઝિટ સરનામું જોઈએ? તો તે હોસ્ટ પર છે, ફોરવર્ડિંગ જાણી જોઈને ગોઠવેલું. શું ગેસ્ટનાં ટ્રાફિકને હોસ્ટના VPN થી સંપૂર્ણ બહાર રહેવું જોઈએ? તો ગેસ્ટ-ટનલ એ એકમાત્ર ગોઠવણ છે જે તે રચનાથી જ આપે છે.
જવાબ VM ના નામની બાજુમાં એક લીટીમાં લખો: guest-owned અથવા host-owned. છ મશીનની લેબમાં તે નોંધ નીચેના કોઈપણ પગલા કરતાં વધુ સમય બચાવે છે, કારણ કે તે તમને એવી ટનલની સમસ્યા શોધતા અટકાવે છે જે તમે જે મશીનમાં લોગિન થયા છો તેમાં કદી હતી જ નહીં.
WSL1 અને WSL2 વિરોધાભાસી કિસ્સા છે
WSL1 વર્ચ્યુઅલ મશીન નથી, તેથી સ્થાનનો પ્રશ્ન મોટે ભાગે વિલીન થાય છે. તેની Linux બાઇનરીઓ અનુવાદ સ્તર દ્વારા Windows ના નેટવર્ક સ્ટેક સામે ચાલે છે, અને Linux VPN ક્લાયન્ટ પાસે ગોઠવવા માટે સ્વતંત્ર ઇન્ટરફેસ હોતા નથી. જે ગોઠવણ કામ કરે છે તે Windows બાજુની ટનલ છે, જેમાં ડિસ્ટ્રિબ્યુશન કંઈ પણ માલિકી વિના પરિણામ વાપરે છે.
WSL2 ઊલટું છે. તે Hyper-V વર્ચ્યુઅલ સ્વિચ પાછળ હલકા યુટિલિટી VM માં વાસ્તવિક કર્નલ ચલાવે છે, અને તેની સરનામા-જગ્યા હોસ્ટ બાજુના એડેપ્ટર દ્વારા NAT થાય છે. તેથી ડિસ્ટ્રિબ્યુશનની અંદરનો Linux ક્લાયન્ટ ભૌતિક Linux બોક્સ પર જેવો વર્તે છે: તે tun0 કે wg0 બનાવે છે, પોતાના રૂટ ગોઠવે છે, અને કામ કરે છે. નિષ્ફળતા હોસ્ટ બાજુ રહે છે. જ્યારે Windows VPN ક્લાયન્ટ એવી નીતિ સાથે જોડાય છે જે સ્થાનિક નેટવર્ક પર ટ્રાફિક અટકાવે છે, ત્યારે તે WSL2 સબનેટને અવિશ્વસનીય સ્થાનિક નેટવર્ક ગણે છે અને NAT માર્ગ કાપી નાખે છે. પછી ડિસ્ટ્રિબ્યુશન DNS અને બહારની પહોંચ ગુમાવે છે જ્યારે તેની પોતાની ટનલ હજી સ્વસ્થ છે: wg show હેન્ડશેક જણાવે છે, ip route બરાબર દેખાય છે, અને curl અટકી જાય છે.
કયો ઉપાય વાપરી શકો તે Windows બિલ્ડ પર આધાર રાખે છે. જૂનો એ WSL સબનેટ માટે હોસ્ટ ક્લાયન્ટમાં અપવાદ છે, જે ક્લાયન્ટની સ્થાનિક-નેટવર્ક કે વિભાજિત-ટનલ સેટિંગ્સ હેઠળ ઉમેરાય છે. નવો, જે Windows 11 બિલ્ડ જે તેને ટેકો આપે છે તેમાં, મિરર્ડ નેટવર્કિંગ છે: %UserProfile%\.wslconfig ના [wsl2] વિભાગમાં networkingMode=mirrored મૂકો, wsl --shutdown ચલાવો, અને ડિસ્ટ્રિબ્યુશન ખાનગી NAT સબનેટને બદલે હોસ્ટના ઇન્ટરફેસ વહેંચશે. મિરર્ડ મોડ localhost અને આવતા પોર્ટનું વર્તન પણ બદલે છે, તેથી તેને ટોગલ નહીં પણ માઇગ્રેશન ગણો.
NAT, બ્રિજ અને હોસ્ટ શું જોઈ શકે
NAT હેઠળ ગેસ્ટનાં ટનલ પેકેટ VPN સર્વરના જાહેર સરનામે મોકલાય છે અને એન્ક્રિપ્ટ થયેલા UDP કે TCP તરીકે હોસ્ટ એડેપ્ટરમાંથી નીકળે છે. હોસ્ટ એક ફ્લો અને તેની બાઇટ-ગણતરી જુએ છે, અંદરના લક્ષ્યો વિશે કંઈ નહીં. બ્રિજ્ડ એડેપ્ટર હેઠળ ગેસ્ટની ભૌતિક LAN પર પોતાની 2-સ્તરીય ઓળખ હોય છે, પોતાનું DHCP લીઝ લે છે, અને MAC આધારિત કોઈપણ નીતિ સામે બીજા ઉપકરણ જેવું દેખાય છે. બંનેમાંથી કોઈ મોડ હોસ્ટને ટનલનો પેલોડ વાંચવા દેતું નથી; બ્રિજ્ડ ગેસ્ટ ફક્ત તેની આસપાસના નેટવર્ક માટે ઘણું વધુ દૃશ્યમાન છે.
અલગીકરણનું પણ નીચું સ્તર છે. ગેસ્ટ પોતાની મેમરી ધરાવતા મશીનથી છુપાઈ શકતું નથી, અને જે હોસ્ટ નિયંત્રિત કરે છે તે ગેસ્ટની RAM માંથી ચાવીઓ વાંચી શકે છે. ગેસ્ટ-ટનલ તમને રૂટિંગ સીમા અને માલવેર સીમા આપે છે, લેપટોપ પકડી બેઠેલી વ્યક્તિથી રક્ષણ નહીં. દસ્તાવેજીકૃત એડેપ્ટર મોડ પસંદ કરતી વખતે ખુલ્લા રાખવા યોગ્ય છે, કારણ કે મોડ હોસ્ટ શું જુએ છે અને LAN શું જુએ છે તે બંને બદલે છે.
માર્ગદર્શિકા: ગોઠવો, રૂપરેખાંકિત કરો, સાબિત કરો
આ ચાર તપાસ ક્રમમાં નવા ગેસ્ટ શેલમાં ચલાવો, અને તમે લખેલા માલિક સાથે ન મળતી પહેલી તપાસ પર થોભો.
ip route get 1.1.1.1tun0કેwg0પરત આપે તો ગેસ્ટ-માલિકી, અને ખાનગી આગલા હોપ સાથેeth0મળે તો હોસ્ટ-માલિકી.resolvectl query example.com, અથવા જ્યાં ગેસ્ટ કોઈ રિઝોલ્વર સેવા ચલાવતું નથી ત્યાં/etc/resolv.confવાંચો. જે ટનલ ટ્રાફિક વહે છે પણ DNS નહીં, તે સૌથી સામાન્ય અડધું-ગોઠવાયેલી સ્થિતિ છે.- એક્ઝિટ સરખાવો: ગેસ્ટમાં
curl -4 -s https://ifconfig.meઅને હોસ્ટ પરcurl.exe -4 -s https://ifconfig.me. અલગ સરનામાં એટલે ગેસ્ટ ટનલનો માલિક છે, અને VPN પરનો હોસ્ટ સાથે ઘરનો ISP દેખાડતું ગેસ્ટ એ કંઈ-વારસામાં-ન-મળ્યું કિસ્સો છે. - બંનેને
-6સાથે પુનરાવર્તન કરો. ફક્ત-v4 ટનલ v6 લીક કરે છે સિવાય કે ક્લાયન્ટ તેને અવરોધે કે રૂટ કરે, અને ઘણા ક્લાયન્ટ ડિફોલ્ટમાં v6 ને ભૌતિક ઇન્ટરફેસ પર જ રહેવા દે છે.
હોસ્ટ-ગેટવે રચનામાં, જ્યાં ઘણા ગેસ્ટ એક ટનલ વહેંચે છે, હોસ્ટે ફોરવર્ડ અને અનુવાદ કરવો પડે. Linux હોસ્ટ પર તે ત્રણ ટુકડા છે, અને તેમાંથી કોઈ પણ ન હોય ત્યારે ગેસ્ટ ચૂપચાપ પોતાના સાદા રૂટ પર પાછું જાય છે:
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE
iptables -A FORWARD -i virbr0 -o wg0 -j ACCEPT
iptables -A FORWARD -i wg0 -o virbr0 -m state --state RELATED,ESTABLISHED -j ACCEPTWireGuard બાજુ પર હોસ્ટ પીઅરનાં AllowedIPs માં ગેસ્ટ સબનેટ સામેલ હોવું જોઈએ, ઉદાહરણ તરીકે 192.168.122.0/24, નહીં તો પરત પેકેટ કદી પહોંચતાં નથી અને ગોઠવણ ફાયરવોલ સમસ્યા જેવી લાગે છે. Windows હોસ્ટ Internet Connection Sharing કે Hyper-V સ્વિચ પર NAT નિયમ વડે એ જ પરિણામ પામે છે, અને એ જ પરત-માર્ગ તપાસ જરૂરી છે.
જ્યારે લેઆઉટ હજી ખુલ્લું હોય, ત્યારે આ કોષ્ટક સૌથી વધુ આવતી ગોઠવણો આવરે છે:
| Situation | Owner | Check first |
|---|---|---|
| One VM, host also on a corporate VPN | Guest | Does the host client block local networks? |
| Six lab VMs, one exit address | Host plus forwarding | ip_forward, NAT rule, server AllowedIPs |
| Malware or research VM | Guest, NAT | Snapshot age and resolver state |
| Bridged VM on an office LAN | Guest | DHCP lease and port security |
બે ટનલ, બે ગેસ્ટ, અને તેમની વચ્ચેના વિરોધાભાસ
જ્યારે એકસાથે બે એક્ઝિટ જોઈએ, ત્યારે ટકતો નમૂનો છે દરેક ગેસ્ટ માટે એક ટનલ. દરેક VM પોતાનો ડિફોલ્ટ રૂટ અને રિઝોલ્વર રાખે છે, હોસ્ટ સામાન્ય નેટવર્ક પર રહે છે, અને બે ટનલ કદી એક જ રૂટિંગ કોષ્ટક માટે ઝઘડતી નથી. બે ગેસ્ટને બ્રિજથી જોડવાથી તેમના રૂટ પણ ભળતા નથી: વર્ચ્યુઅલ નેટવર્ક માર્ગ આપે છે, અને દરેક ક્લાયન્ટને હજી પણ કહેવું પડે છે કે આ સ્થાનિક ટ્રાફિક ટનલને ટાળી શકે છે.
હોસ્ટ ટનલ અને ગેસ્ટ ટનલ સાથે ચલાવવી વાજબી છે, અને જાણી જોઈને નેસ્ટિંગ કરવું ક્યારેક બરાબર એ જ હોય છે જે તમને જોઈએ—ગેસ્ટ પોતાની ટનલમાંથી નીકળે અને તે ટનલ હોસ્ટની ટનલમાંથી નીકળે. તેને વિક્ષેપમાં ફેરવે છે એ વાત કે કોઈએ લખ્યું નથી કે કયો અંતિમબિંદુ કયા સ્તરથી પહોંચવો છે. લક્ષ્ય અને માલિકની બે-કૉલમ યાદી રાખો, અને રૂટ વિરોધાભાસ એક બપોરની શોધને બદલે એક શોધ બની જાય છે.
ચકાસો, પછી પુનઃપ્રાપ્તિ માલિક પાસે રાખો
ગેસ્ટની અંદરથી પરીક્ષણ કરો નવી એપ્લિકેશન પ્રક્રિયા સાથે: ટ્રાફિક, નામ-ઉકેલ, બંને સરનામા-કુટુંબ, અને ટનલ પડે ત્યારે શું થાય. હોસ્ટનું VPN આઇકન ગેસ્ટના આવરણ વિશે કંઈ કહેતું નથી, અને આ આખા ક્ષેત્રમાં એ જ સૌથી સામાન્ય ખોટી પુષ્ટિ છે.
પુનઃપ્રાપ્તિ પણ માલિકની જ છે. ગેસ્ટ-માલિકીની ટનલ ગેસ્ટના પોતાના ક્લાયન્ટ અને તેણે લખેલા રૂટ દ્વારા પુનઃસ્થાપિત થાય છે. હોસ્ટ-માલિકીની રચના હોસ્ટના બૂટ-ક્રમ દ્વારા પુનઃસ્થાપિત થાય છે, અને ફોરવર્ડિંગ નિયમો રીબૂટમાં ટકતા નથી સિવાય કે કોઈ unit કે સ્ટાર્ટઅપ કાર્ય તેમને ફરી લાગુ કરે. પુનઃસ્થાપિત સ્નેપશોટ એ ડિપ્લોયમેન્ટ છે, રદ નહીં, કારણ કે તે ડિસ્ક સાથે જૂનાં ક્રેડેન્શિયલ અને જૂના રૂટ પાછા લાવે છે. કામ પૂરું કહેતા પહેલાં ખાતરી કરો કે માલિક હજી તમે લખેલી લીટી સાથે મળે છે, DNS અને બંને સરનામા-કુટુંબ ગેસ્ટની અંદર ઉકેલાય છે, મૃત ટનલ કાળા છિદ્રને બદલે વાપરી શકાય તેવું નેટવર્ક છોડે છે, અને રીબૂટ કે સ્નેપશોટ પુનઃસ્થાપન એ જ સ્થિતિ ફરી ઉત્પન્ન કરે છે.