ગેસ્ટ VPN અને હોસ્ટ VPN: કયો રૂટ ખરેખર જીતે છે

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

પહેલા ગેસ્ટનું જોડાણ નોંધો

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

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

ગેસ્ટનો એન્ડપૉઇન્ટ બહારની તરફ અનુસરો

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

બંને સંદર્ભોમાં પહોળો રૂટ બીજા ક્લાયન્ટે ધારેલો ટ્રાફિક પકડી લે છે. ગેસ્ટની અંદર 0.0.0.0/0 રૂટ અને પૂર્ણ-ટનલ હોસ્ટ ક્લાયન્ટ બંને બધું જ દાવો કરે છે, અને છેવટે જે લાગુ પડે તે જીતે છે. ગેસ્ટના વર્ચ્યુઅલ નેટવર્ક, સ્થાનિક LAN અને દૂરસ્થ નેટવર્ક વચ્ચેનું ઓવરલેપ ખાનગી પ્રીફિક્સ માટે એ જ અસર કરે છે, નિષ્ફળતાઓ પ્રમાણીકરણની સમસ્યા જેવી લાગે છે; સરનામા અનુવાદનું વર્તન એ જ છે જે કન્ટેનર નેટવર્કિંગ માટે વર્ણવ્યું છે.

પહેલાં અને પછીની નોંધ સરખાવો

હોસ્ટની ટનલ બંધ રાખીને, અથવા તમારી નીતિ જે નિયંત્રિત સ્થિતિ મંજૂર કરે તેમાં આધારરેખા લો, અને ગેસ્ટનો રૂટ અને રિઝૉલ્વર નોંધો. પછી સંયુક્ત રૂપરેખા લાગુ કરો અને બે નોંધ સરખાવો, ગોપનીયતાની જરૂરિયાતો અકબંધ રાખીને. સીધી આધારરેખા યોગ્ય ન હોય તો સરખામણી છોડવાને બદલે એ મર્યાદા નોંધમાં લખો.

ip route get 10.20.30.41
ip rule show
resolvectl status --no-pager | head -12

રૂટ ક્વેરી કઈ ઇન્ટરફેસ અને સ્રોત સરનામું ચોક્કસ ગંતવ્ય વહન કરશે તે જણાવે છે, અને આ તપાસમાં તે સૌથી ઉપયોગી લીટી છે. નિયમોની યાદી બતાવે છે કે નીતિ-રાઉટિંગ કેટલાંક ગંતવ્યોને બીજા કોષ્ટક દ્વારા મોકલે છે કે નહીં. રિઝૉલ્વરનું આઉટપુટ બતાવે છે કે DNS એ ગેસ્ટની ટનલ અનુસરી કે હોસ્ટના માર્ગે જ રહ્યું. ફેરફાર પહેલાં અને પછી એ જ ત્રણ આદેશો ચલાવો, અને તફાવત દોષિતનું નામ બોલશે.

રીસ્ટાર્ટ દરમિયાન માલિકી સ્પષ્ટ રાખો

હોસ્ટ ક્લાયન્ટની સ્થાનિક-ઍક્સેસ મર્યાદા વર્ચ્યુઅલ NAT કે બ્રિજ તરફનો ટ્રાફિક અવરોધી શકે છે, અને એ મર્યાદાને વારંવાર ગેસ્ટની ઓળખપત્ર સમસ્યા ગણી લેવાય છે. પરીક્ષણ પાસ કરાવવા માટે મર્યાદા નિષ્ક્રિય કરવાને બદલે ક્લાયન્ટનું દસ્તાવેજીકૃત વર્તન વાંચો. સમર્થિત સુધારા પછી ગેસ્ટ એપ્લિકેશન અને તમે જરૂરી ગણો તે નિષ્ફળતા-નીતિ ફરી ચકાસો. સફળતાપૂર્વક ફરી જોડાતું હોસ્ટ ગેસ્ટના રૂટ કે રિઝૉલ્વર વિશે કંઈ સાબિત કરતું નથી.

કઈ બાજુ ડિફૉલ્ટ રૂટની માલિક છે તે નક્કી કરો અને તે ઑપરેશન પુસ્તિકામાં લખો. ગેસ્ટનો રીસ્ટાર્ટ અથવા હોસ્ટ પર નેટવર્ક બદલાવ જે માલિકી ચૂપચાપ ઉલટાવી દે છે, તે એવા VPN વિશે બગ રિપોર્ટ બનાવે છે જે ક્યારેય દોષિત નહોતું. ગોઠવણ રીબૂટ પછી પણ ટકી રહેવી જોઈએ, કોઈને યાદ ન હોય કે તે કેમ કામ કરતી હતી.