શું તમારું VM હોસ્ટનું VPN વાપરે છે? ગેસ્ટની અંદરથી પરીક્ષણ કરો

તમે હોસ્ટનું પબ્લિક IP તપાસો છો, તે VPN બતાવે છે, અને તમે નિષ્કર્ષ કાઢો છો કે VM આવરી લેવાયું છે. આ નિષ્કર્ષને પરીક્ષણ ટેકો આપતું નથી. ગેસ્ટનું પોતાનું રૂટિંગ ટેબલ, પોતાનું રિઝોલ્વર અને પોતાના ઇન્ટરફેસ છે, અને હોસ્ટનું એક્ઝિટ સરનામું તેમના વિશે કંઈ કહેતું નથી.

પરીક્ષણ ગેસ્ટની અંદર ચલાવવું પડશે, અને તેણે શું માપ્યું તેનું નામ આપવું પડશે.

ગેસ્ટની અંદર શરૂ કરો, હોસ્ટના બ્રાઉઝરમાં નહીં

પહેલાં હાઇપરવાઇઝરનો નેટવર્ક મોડ નોંધો: NAT, bridged, host-only અથવા macvtap. NAT મોડમાં હોસ્ટ ગેસ્ટનો ટ્રાફિક રૂટ કરે છે, તેથી ક્લાઇએન્ટ રૂટ કેવી રીતે ઇન્સ્ટોલ કરે છે તેના આધારે હોસ્ટનું ટનલ લાગુ થઈ શકે અથવા ન પણ થાય. bridged મોડમાં ગેસ્ટ ભૌતિક LAN પર સમકક્ષ છે અને હોસ્ટનું ટનલ અપ્રસ્તુત છે. આ બે મોડ એક જ હોસ્ટ રૂપરેખાંકનથી વિરોધી જવાબો આપે છે.

કંઈપણ બદલતા પહેલાં મોડ લખી લો, કારણ કે પરિણામનો અર્થ શું હોઈ શકે તે તે નક્કી કરે છે.

એક વિનંતી કરો જેનું ગંતવ્ય તમે જાણો છો

એવી સેવાને નિરુપદ્રવી વિનંતી મોકલો જે તેણે જોયેલું સ્રોત સરનામું જણાવે છે. પછી તે ગંતવ્ય માટે ગેસ્ટના પોતાના રૂટિંગ નિર્ણયને તપાસો: ip route get 203.0.113.5 ગેસ્ટ જે ઇન્ટરફેસ અને ગેટવે વાપરશે તે છાપે છે.

જો ઇન્ટરફેસ ગેસ્ટનું સામાન્ય NIC હોય, તો ટ્રાફિક ગેસ્ટની અંદરના ટનલમાંથી પસાર થતો નથી.

બીજું એડેપ્ટર, પ્રોક્સી સેટિંગ અથવા ગેસ્ટ-સાઇડ VPN ક્લાઇએન્ટ એક એપ્લિકેશન માટે જવાબ બદલી શકે છે અને બીજી માટે નહીં. તમને ખરેખર જે એપ્લિકેશનની પરવા છે તેનું પરીક્ષણ કરો, શેલમાંથી સામાન્ય વિનંતી નહીં.

રિઝોલ્વર અલગથી તપાસો

બદલાયેલું એક્ઝિટ સરનામું તમને કહેતું નથી કે કયા રિઝોલ્વરે હોસ્ટનામ સંભાળ્યું. પ્લેટફોર્મને અનુરૂપ સાધન સાથે નામ સ્પષ્ટ રીતે પૂછો, અને કયા સર્વરે જવાબ આપ્યો તે નોંધો. વિભાજિત DNS એટલે કે રિઝોલ્વર પ્રશ્ન અને રૂટિંગ પ્રશ્નના જવાબ અલગ છે.

આ બે કોઈપણ દિશામાં અલગ પડી શકે છે, અને આ અંતર ઘણી વાર ખરેખરી ભૂલ હોય છે.

systemd હોસ્ટ પર, resolvectl query જવાબની પાછળનું ઇન્ટરફેસ અને DNS સર્વરનું નામ આપે છે. જૂની સેટિંગ્સ સર્વરને dig આઉટપુટમાં બતાવે છે — કોઈપણ રીતે મુદ્દો એ જોવાનો છે કે કયા સર્વરે જવાબ આપ્યો, ફક્ત જવાબ આવ્યો કે નહીં તે નહીં.

નિષ્ફળતા નીતિનું પરીક્ષણ કરો, ફક્ત સફળતાનું નહીં

જો જરૂરિયાત એ છે કે ટનલની બહાર કોઈ ટ્રાફિક ન જાય, તો સફળ વિનંતી કંઈ સાબિત કરતી નથી. ક્લાઇએન્ટનું સમર્થિત નિયંત્રિત નિષ્ફળતા પરીક્ષણ વાપરો: ટનલને સમર્થિત રીતે બંધ કરો અને જુઓ કે ગેસ્ટની નવી વિનંતી અવરોધાય છે કે નહીં. એવું ન ધારો કે હોસ્ટ ક્લાઇએન્ટનું kill switch દરેક વર્ચ્યુઅલ ફોરવર્ડિંગ ગોઠવણને આવરી લે છે. તેનો દસ્તાવેજીકૃત વ્યાપ એ જ એકમાત્ર વસ્તુ છે જેના પર તમે આધાર રાખી શકો.

ટનલ પડે ત્યારે જે ગેસ્ટ ભૌતિક NIC પર પાછું જાય છે તે બરાબર એ જ કરે છે જે NAT મોડ માન્ય કરે છે.

મોડ અને વ્યાપ નોંધો

હાઇપરવાઇઝર મોડ, ગેસ્ટનું ઇન્ટરફેસ અને રૂટ, રિઝોલ્વર અને તમે ચકાસેલી એપ્લિકેશન લખો. તારીખ ઉમેરો, કારણ કે સ્નેપશોટ પુનઃસ્થાપન અથવા હાઇપરવાઇઝર અપડેટ ચારેય બદલી શકે છે.

જો IPv4 ટનલને અનુસર્યું, તો તે કહો. દાવાને IPv6, બીજા નામસ્થાન અથવા બીજા નેટવર્કના બીજા VM સુધી લંબાવશો નહીં.