NAT કે બ્રિજ VM નેટવર્ક: VPN ટ્રાફિક કોણ વહન કરે છે?

NAT મહેમાનો હોસ્ટ ટનલ ત્યારે જ ઉધાર લે છે જ્યારે ક્લાયન્ટ રૂટ દ્વારા ટનલ કરે; બ્રિજ મહેમાનો પોતે રૂટ કરે છે. મહેમાનનું પરીક્ષણ કરો અને પછી અનુકૂળ મોડ પસંદ કરો.

બ્રિજ અને NAT એક જ મહેમાનને તમારા VPN સાથે જોડવાની બે રીતો નથી; તેઓ નક્કી કરે છે કે કોઈ પણ ટનલ આવે તે પહેલાં મહેમાનના પેકેટ કોના છે. NAT મોડમાં હાઇપરવાઇઝર મહેમાનનો ટ્રાફિક ફરીથી લખે છે અને તેને હોસ્ટ બાજુના કોડમાંથી મોકલે છે, તેથી મહેમાન તે રૂટ પર જાય છે જે હોસ્ટ તે કોડને આપે છે. બ્રિજ મોડમાં મહેમાન ભૌતિક સેગમેન્ટ પર તેની પોતાની લિંક-લેયર ઓળખ મેળવે છે અને તેનું પોતાનું ડિફોલ્ટ ગેટવે પસંદ કરે છે, જે હોસ્ટની ટનલને તેના માટે અપ્રસ્તુત બનાવે છે, સિવાય કે LAN રાઉટર જ ટનલ કરતું હોય. મેં VM ને VPN પર હોવાનું ગણવાનું બંધ કર્યું અને તે મહેમાનનું ડિફોલ્ટ રૂટ ક્યાં ઇશારો કરે છે તે પ્રશ્ન તરીકે જોવાનું શરૂ કર્યું. નીચેનું પરીક્ષણ દરેક મોડ માટે થોડી મિનિટ લે છે અને અનુમાન વિના તેને સ્પષ્ટ કરે છે.

NAT મહેમાનને હાઇપરવાઇઝર કોડ પાછળ રાખે છે, જ્યાં હોસ્ટના રૂટ લાગુ પડે છે

VirtualBox માં NAT મહેમાન 10.0.2.0/24 પર બેસે છે, 10.0.2.2 પર વર્ચ્યુઅલ ગેટવે, 10.0.2.3 પર DNS પ્રોક્સી અને ભૌતિક નેટવર્ક સુધીનો પોતાનો કોઈ રૂટ નથી. બહાર જતા પેકેટ NAT એન્જિન લે છે, સ્રોત હોસ્ટ હોય તે રીતે ફરીથી લખે છે અને હોસ્ટના IP સ્ટેકને સોંપે છે. ત્યાંથી મહેમાનનો ટ્રાફિક હોસ્ટ ફ્લો છે, અને રૂટ શોધ ગંતવ્ય પ્રમાણે થાય છે: સંપૂર્ણ ટનલ ક્લાયન્ટ જે હોસ્ટ પર 0.0.0.0/1 અને 128.0.0.0/1 સ્થાપિત કરે છે તે તેને પકડી લે છે, VM છે તે ક્યારેય જાણ્યા વિના. Oracle નું VirtualBox નેટવર્કિંગ પ્રકરણ આ ડિફોલ્ટ સૂચિબદ્ધ કરે છે, જો તમે તમારા બિલ્ડ પર સરનામાં ખાતરી કરવા માગતા હો.

libvirt નું ડિફોલ્ટ નેટવર્ક 192.168.122.0/24 થી એ જ જગ્યાએ પહોંચે છે, જ્યાં dnsmasq લીઝ આપે છે અને હોસ્ટ સબનેટનું માસ્કરેડ કરે છે, તેથી મહેમાનના પેકેટ ફરી હોસ્ટના રૂટિંગ નિર્ણય પાસે આવે છે. અપવાદ એ ક્લાયન્ટ છે જે ટ્રાફિક રૂટ પ્રમાણે નહીં પણ પ્રોસેસ પ્રમાણે પસંદ કરે છે. જો સ્પ્લિટ-ટનલ યાદીમાં ફક્ત તમારો બ્રાઉઝર હોય અને બીજું કંઈ ન હોય, તો NAT એન્જિન તે યાદીમાં નથી, અને મહેમાન મશીનમાંથી ટનલ વિના નીકળે છે જ્યારે હોસ્ટનું બ્રાઉઝર હજી ઢંકાયેલું દેખાય છે. એ જ સબનેટ, વિરોધી પરિણામ.

બ્રિજ મહેમાનને ભૌતિક LAN પર તેનું પોતાનું સ્થાન આપે છે

બ્રિજ મહેમાનને વાસ્તવિક એડેપ્ટર સાથે જોડાયેલ વર્ચ્યુઅલ NIC આપવામાં આવે છે, તેને પોતાનું MAC સરનામું મળે છે અને ભૌતિક નેટવર્કથી DHCP લીઝ લે છે. તેનું ડિફોલ્ટ ગેટવે LAN રાઉટર છે, હાઇપરવાઇઝર નહીં, અને તેના ફ્રેમ તે એડેપ્ટર દ્વારા વાયર પર જાય છે. હોસ્ટના ટનલ રૂટ હોસ્ટના ટેબલમાં રહે છે અને તેમને ક્યારેય પૂછવામાં આવતું નથી, કારણ કે મહેમાનના ફ્રેમ ક્યારેય હોસ્ટના IP સ્ટેકમાં પ્રવેશતા નથી.

આ બંને દિશામાં કાપે છે. mDNS અને SMB બ્રાઉઝિંગ કામ કરવા લાગે છે કારણ કે મહેમાનને LAN પ્રસારણ ટ્રાફિક દેખાય છે, અને મહેમાન વચ્ચે હોસ્ટ ફાયરવોલ વિના તે જ સેગમેન્ટના બીજા મશીનોથી પહોંચી શકાય છે. બ્રિજ એ હાલની ટનલ દ્વારા મહેમાનને દબાણ કરવાની રીત પણ નથી: VM ને હોસ્ટની WireGuard અથવા OpenVPN ઇન્ટરફેસ સાથે જોડવું એ VirtualBox કે libvirt તમારા માટે કરે તેવું કંઈ નથી. જો બ્રિજ મહેમાનને ટનલમાંથી પસાર થવું હોય, તો ટનલ તે LAN પર ક્યાંક સમાપ્ત થવી જોઈએ.

જે દલીલનો અંત લાવે તે પરીક્ષણ

બંને મોડમાં સમાન તપાસ ચલાવો અને જવાબ લખો:

  • હોસ્ટ પર, curl -s https://ifconfig.me જાહેર v4 સરનામું આપે છે.
  • મહેમાનમાં, એ જ આદેશ, ઉપરાંત ડિફોલ્ટ ગેટવે માટે Linux પર ip route અથવા Windows પર Get-NetRoute -DestinationPrefix 0.0.0.0/0.
  • રિઝોલ્વરની ઓળખ: મહેમાનમાં resolvectl status અથવા cat /etc/resolv.conf, તે 10.0.2.3 તરફ ઇશારો કરે છે કે LAN સર્વર તરફ તે જોવા માટે.
  • સરનામા કુટુંબ: ip -6 addr show scope global અને એક v6 વિનંતી, કારણ કે v4 ટનલ મહેમાન પાસે હોઈ શકે તેવા વૈશ્વિક v6 સરનામા વિશે કંઈ કહેતી નથી.

મેળ ખાતા જાહેર સરનામાં એટલે મહેમાન હોસ્ટના માર્ગ પર છે. LAN ના સામાન્ય નિકાસ સાથે મેળ ખાતું મહેમાન સરનામું એટલે તે નથી. જે પગલું લોકો ચૂકી જાય છે તે નિયંત્રણ છે: હોસ્ટની ટનલ નીચે ઉતારો અને મહેમાનની વિનંતી ફરીથી કરો. જો મહેમાન બ્રાઉઝ કરવાનું ચાલુ રાખે, તો તે ક્યારેય હોસ્ટની ટનલ પર આધારિત ન હતું, મોડનું નામ શું સૂચવે તે પછી પણ. NAT મોડમાં હોસ્ટની ટનલ નીચે હોય ત્યારે મહેમાને ઇન્ટરનેટ ગુમાવવું જોઈએ, સિવાય કે ક્લાયન્ટ ટનલ વિનાના ટ્રાફિકને મંજૂરી આપવા સેટ થયેલ હોય, જે પોતે જાણવા જેવું છે.

બે સંકેત ખોટા બોલે છે. સફળ પિંગ પહોંચ સાબિત કરે છે, નિકાસ માર્ગ નહીં. અને DNS નો જવાબ 10.0.2.3 પ્રોક્સી દ્વારા હોસ્ટના રિઝોલ્વર થકી મળી શકે છે જ્યારે TCP બીજો રૂટ લે છે, અને એ રીતે તમને એવું પૃષ્ઠ મળે છે જે લોડ થાય છે અને એવું લોગિન જે ક્યારેય પૂરું થતું નથી.

કામ માટે કયો મોડ યોગ્ય છે

મોડ એ રૂટિંગ નિર્ણય છે, તેથી તેને ટેવ પ્રમાણે નહીં પણ જરૂરિયાત પ્રમાણે પસંદ કરો:

RequirementMode that fits
Every guest flow must exit through the host tunnelNAT, with a host client that tunnels by route, verified from inside the guest
The guest needs its own VPN account or profileBridged, or NAT with a client running inside the guest, not both
The guest must serve SSH, SMB, or a dev server to the LANBridged; NAT needs a port forward, which does not change the outbound path
The guest must stay invisible to the LANNAT; a bridged guest is another host on the segment
The guest needs a real public IPv6 addressBridged; VirtualBox NAT mode has no IPv6 forwarding
Isolation from the LAN with access to the hostHost-only adapter, not NAT

પ્રથમ પંક્તિ એ છે જ્યાં લોકો ફસાય છે: NAT સાથે હોસ્ટ પર સંપૂર્ણ ટનલ ક્લાયન્ટ મહેમાનને આવરી લે છે, પણ ત્યારે જ જ્યારે ક્લાયન્ટ રૂટ દ્વારા ટનલ કરે અને હોસ્ટનું અપલિંક તે ટનલ હોય. ક્લાયન્ટને ફક્ત બ્રાઉઝર માટેની મંજૂરી યાદીમાં ખસેડો અને ક્યાંય પણ કોઈ ભૂલ વિના આવરણ અદૃશ્ય થઈ જાય છે. ચોથી પંક્તિ વિરુદ્ધ ભૂલ છે: સુવિધા માટે બ્રિજ કરેલ મહેમાન જે ઓફિસના LAN પર ચૂપચાપ SMB કે SSH નો જવાબ આપવા લાગે છે.

VPN પર ઠારણ મૂકાતી નિષ્ફળતાઓ

Windows પર NAT અનુવાદ VirtualBox VM પ્રોસેસની અંદર ચાલે છે, તેથી પ્રતિ-એપ ક્લાયન્ટને વર્ચ્યુઅલ મશીનો માટે સામાન્ય નિયમને બદલે તેની યાદીમાં એ જ ઇમેજ જોઈએ. જ્યારે ક્લાયન્ટ અપડેટ તેની પ્રોસેસ યાદી ફરીથી બનાવે છે, ત્યારે NAT મહેમાનો પહેલા આવરણ ગુમાવે છે, અને અહેવાલ એવો વંચાય છે કે VM LAN સુધી પહોંચે છે પણ ઇન્ટરનેટ સુધી નહીં, જ્યારે હોસ્ટ ઠીક છે.

Wi-Fi પર બ્રિજ કરવું બીજું ક્લાસિક છે. એક્સેસ પોઇન્ટ ભાગ્યે જ વિદેશી સ્રોત MAC ધરાવતા ફ્રેમ ફોરવર્ડ કરે છે, તેથી wlan0 પરનો બ્રિજ ક્યાં તો સંપૂર્ણ નિષ્ફળ જાય છે અથવા ત્યાં સુધી કામ કરે છે જ્યાં સુધી AP પર ક્લાયન્ટ અલગીકરણ તેને છોડવા લાગે. VirtualBox તેમ છતાં તેની યાદીમાં વાયરલેસ એડેપ્ટર આપશે. જો હોસ્ટ Wi-Fi પર હોય અને મહેમાનને બ્રિજ કરવાનું હોય, તો ધારવાને બદલે તેને ચકાસવાનું આયોજન કરો.

MTU ત્રીજું છે. બ્રિજ મહેમાન LAN નું 1500 બાઇટ MTU રાખે છે, અને જો તે 1420 પર પોતાનું WireGuard ક્લાયન્ટ ચલાવે, તો મોટા TLS હેન્ડશેક અટકી જાય છે જ્યારે નાની વિનંતીઓ સફળ થાય છે. NAT હેઠળ હોસ્ટ ટનલનું MTU હોસ્ટની સમસ્યા છે, પણ મહેમાન હજી 1500 માને છે, અને don't-fragment બિટ સેટ સાથેનું UDP એ જ રીતે અદૃશ્ય થાય છે.

મોડ નોંધો અને દરેક એડેપ્ટર ફેરફાર પછી ફરી તપાસો

મોડ, બ્રિજ વાપરતું હોસ્ટ ઇન્ટરફેસ, મહેમાનનું ડિફોલ્ટ ગેટવે, તેનું રિઝોલ્વર અને તેના v4 અને v6 નિકાસ સરનામાં નોંધો. એ નોંધ જ આગલી નિષ્ફળતાને સસ્તી બનાવે છે: જ્યારે લેપટોપ ડોકથી Wi-Fi પર જાય છે, ત્યારે બ્રિજ મહેમાન બ્રિજને બીજા ભૌતિક એડેપ્ટર તરફ અનુસરે છે અને બીજા સબનેટમાં ફરી લીઝ લઈ શકે છે, જ્યારે NAT મહેમાન તેનું 10.0.2.x સરનામું રાખે છે અને ચૂપચાપ બીજું અપલિંક વારસામાં લે છે.

ટિકિટ બંધ કરતા પહેલા, આમાંથી દરેકની ખાતરી કરો:

  • મહેમાનનું નિકાસ સરનામું હોસ્ટના નિકાસ સરનામાથી અલગ છે, તેથી તે હોસ્ટની ટનલ પર નથી.
  • રિઝોલ્વર 10.0.2.3 પ્રોક્સી છે અથવા LAN સર્વર છે, અને તમે જાણો છો કે કોણે જવાબ આપ્યો.
  • જો ટનલ ડિઝાઇન ફક્ત v4 હોય તો મહેમાનમાં કોઈ વૈશ્વિક v6 સરનામું નથી.
  • હોસ્ટની ટનલ નીચે હોય ત્યારે મહેમાન બ્રાઉઝ કરવાનું બંધ કરે છે, અથવા હવે તમે જાણો છો કે તે ક્યારેય તેના પર આધારિત ન હતું.
  • મહેમાનને એવો LAN પ્રસારણ ટ્રાફિક દેખાતો નથી જે તેની સાથે સંબંધિત નથી.

સંબંધિત લેખો