બીજું VPN ટનલ પ્રથમને કેમ તોડે છે?
બીજું VPN ક્લાયન્ટ બે અર્ધ-ડિફોલ્ટ રૂટ ઇન્સ્ટોલ કરે છે અને પ્રથમ ટનલ અંધારું થઈ જાય છે: કયો રૂટ જીતે છે તે વાંચો, પછી પ્રોફાઇલ, ટેબલ કે નેમસ્પેસ દ્વારા વિભાજિત કરો.
એક ગ્રાહક નેટવર્ક સુધી પહોંચવા માટે બીજું VPN ક્લાયન્ટ ઇન્સ્ટોલ કરવું એ સામાન્ય રીતે આ રીતે શરૂ થાય છે, અને બંને ક્લાયન્ટ સફળતા જાહેર કરે ત્યારે પ્રથમ ટનલ અંધારું થઈ જાય છે. દરેક ક્લાયન્ટે ડિફોલ્ટ રૂટ ઇન્સ્ટોલ કર્યો, બીજો વધુ ચોક્કસ હતો, અને કર્નલ હવે પ્રથમ ટનલના પોતાના બાહ્ય જોડાણ સિવાય બાકી બધા માટે તેને અનુસરે છે. કંઈ તૂટ્યું નથી અને કોઈ પ્રોફાઇલ ખોટું નથી. એક રૂટે બીજાને બદલ્યો, અને ઉકેલ એ છે કે કઈ ટનલ ડિફોલ્ટની માલિક હોવી જોઈએ તે નક્કી કરવું.
લક્ષણ: બીજો ક્લાયન્ટ શાંતિથી જીતે છે
OpenVPN: redirect-gateway def1 વિકલ્પ 0.0.0.0/0 ને ફરી લખતો નથી. તે 0.0.0.0/1 અને 128.0.0.0/1 ઉમેરે છે: બંને મળીને દરેક IPv4 સરનામું આવરી લે છે, અને દરેક પ્રીફિક્સ લંબાઈમાં સામાન્ય ડિફોલ્ટને હરાવે છે. મૂળ ડિફોલ્ટ ટેબલમાં રહે છે અને સામાન્ય ટ્રાફિક માટે વપરાવાનું બંધ કરે છે, અને VPN સર્વર તરફનો હોસ્ટ રૂટ ટનલને તેના પોતાના બાહ્ય પેકેટ પકડતા અટકાવે છે. બંને ક્લાયન્ટ આ કરે છે, અને બીજો ફક્ત પોતાની જોડી પછી ઇન્સ્ટોલ કરે છે.
તેથી પ્રથમ ટનલ ડિસ્કનેક્ટેડને બદલે મૃત દેખાય છે. તેનું ઇન્ટરફેસ ઉપર છે, તેનું કંટ્રોલ ચેનલ જીવંત છે, અને હવે કોઈ એપ્લિકેશન ટ્રાફિક તેના સુધી પહોંચતું નથી. વિરુદ્ધ ફરિયાદમાં પણ એ જ ગુમ થયેલો પુશ છે: જોડાય છે પણ કંઈ મોકલતો નથી એવો ફોન સામાન્ય રીતે એવા સર્વર સાથે વાત કરે છે જેણે ક્યારેય redirect-gateway જાહેર કર્યું નથી, તેથી ઉપકરણ પોતાનું ડિફોલ્ટ રાખે છે અને ફક્ત પૂલ સુધી પહોંચે છે.
બીજો ક્લાયન્ટ જોડાય તે પહેલાં અને પછી રૂટિંગ સ્નેપશોટ લો. ટેબલમાં દેખાતા બે અર્ધ-રૂટ એ આખો ફેરફાર છે, અને તે બંને ફરિયાદો સમજાવે છે. લક્ષણ દેખાવા માટે ટેબલમાં બીજું કંઈ ખસેડવાની જરૂર નથી. તેથી બીજો ક્લાયન્ટ દૂર કરવાથી પ્રથમ તરત જ પાછો આવે છે.
કઈ ટનલ ખરેખર જીતે છે તે વાંચો
ક્લાયન્ટ કયા ક્રમમાં શરૂ થયા તેમાંથી અથવા ટ્રેમાંના આઇકનમાંથી વિજેતા અનુમાન ન કરો. કર્નલને પૂછો કે બંને ખાનગી નેટવર્કની બહારના લક્ષ્ય માટે તે કયો રૂટ વાપરશે, અને પરત આવતું ઇન્ટરફેસ વાંચો.
ip route show
ip route get 198.51.100.24
route print -4
Find-NetRoute -RemoteIPAddress 198.51.100.24
પ્રથમ બે લિનક્સનો જવાબ છે અને છેલ્લા બે વિન્ડોઝનું સમકક્ષ છે. બંને ટનલ ચાલુ હોય ત્યારે તેમને ચલાવો, પછી એકને ડિસ્કનેક્ટ કરો અને ફરી ચલાવો. બંને આઉટપુટ વચ્ચેનો તફાવત એ હકીકત છે જે ઉકેલ પસંદ કરતા પહેલાં તમને જોઈએ છે, અને તે કોઈપણ ક્લાયન્ટનો લોગ વાંચવા કરતાં ઓછો સમય લે છે.
પરિણામ નોંધો, ઇન્ટરફેસનું નામ અને મેળ ખાધેલા પ્રીફિક્સ સહિત. બીજા VPN એ પ્રથમને તોડ્યું એમ કહેતું ટિકિટ લક્ષણનું વર્ણન છે, એવું રૂટિંગ વિધાન નથી જેના પર કોઈ કાર્ય કરી શકે. શોધ તેને એ હકીકતમાં ફેરવે છે જે આગલો એન્જિનિયર એક આદેશમાં પુનઃઉત્પાદન કરી શકે.
વિન્ડોઝ: એક પ્રોફાઇલને ડિફોલ્ટની માલિકી લેતા રોકો
વિન્ડોઝ સંગ્રહિત પ્રોફાઇલ રાખે છે, અને બિલ્ટ-ઇન ક્લાયન્ટ એકને બીજા પર નિર્ભર રહેવા દે છે જેથી બીજું ડાયલ કરે ત્યારે પ્રથમ આપમેળે ઉપર આવે. જે પ્રોફાઇલ સૌથી છેલ્લે જોડાયું તે ડિફોલ્ટ રાખવાનું વલણ ધરાવે છે, તેથી વ્યવહારુ માલિક પ્રથમ નહીં પણ છેલ્લું ડાયલ છે. દરેક પ્રોફાઇલને તેના પોતાના પુશ રૂટ આપો અને જેને ડિફોલ્ટ ન હોવો જોઈએ તેના માટે સ્પ્લિટ ટનલિંગ ચાલુ કરો.
Set-VpnConnection -Name "Contoso" -SplitTunneling $true
rasdial Contoso
સ્પ્લિટ ટનલિંગ તેને બદલે છે: ટેબલમાં ફક્ત સર્વર દ્વારા પુશ કરેલા પ્રીફિક્સ જ આવે છે, જે ડિફોલ્ટ પ્રથમ ટનલ પાસે રાખે છે. જો બંને સર્વર ડિફોલ્ટ રૂટ પુશ કરે તો ડિઝાઇન હજી પણ નિષ્ફળ જાય છે, કારણ કે ત્યારે છેલ્લું જોડાણ જીતે છે અને ક્લાયન્ટ-સાઇડનું કોઈ સેટિંગ તેને બદલતું નથી. સર્વર-સાઇડ પુશ સુધારો અથવા એક માલિક સ્વીકારો.
એપ-ટ્રિગર થતી પ્રોફાઇલ અલગ સુવિધા છે અને જાણવા જેવી છે: વિન્ડોઝ પ્રોફાઇલ નામિત એક્ઝિક્યુટેબલ શરૂ થાય ત્યારે શરૂ થઈ શકે છે, જેમાં ટ્રાફિક ફિલ્ટર નક્કી કરે છે કે તે શું વહન કરશે. આ ફાયરવોલ નિયમ નહીં પણ પ્રોફાઇલ સેટિંગ છે, અને તે ડિફોલ્ટ-રૂટ સંઘર્ષથી અલગ સમસ્યા હલ કરે છે.
લિનક્સ: બીજી ટનલને મુખ્ય ટેબલની બહાર રાખો
એક મશીન પર બે openvpn --config ઇન્સ્ટન્સ ચલાવવાથી બંને ક્લાયન્ટ એક જ ટેબલમાં આવે છે, અને ત્રણ વિકલ્પો વધતા આઇસોલેશન સાથે તેમને અલગ કરે છે. સૌથી હલકો વિકલ્પ બીજા ક્લાયન્ટને ટેબલ સંપાદિત કરતા સંપૂર્ણ રોકવાનો છે: સ્પષ્ટ રૂટ સાથે route-nopull, અથવા route-up સ્ક્રિપ્ટ જે ફક્ત તમે ઇચ્છો તે ઇન્સ્ટોલ કરે. પછી બીજી ટનલ તમે નામ આપો તે જ પ્રીફિક્સ વહન કરે છે અને બીજું કંઈ નહીં. પછી તમે નક્કી કરો છો કે કયા પ્રીફિક્સ ક્યાં જાય, પછી શોધવાને બદલે.
પોલિસી રૂટિંગ મધ્યમ વિકલ્પ છે. એક નિયમ એક સ્રોત સરનામા કે ફાયરવોલ માર્ક માટે અલગ ટેબલ પસંદ કરે છે, અને તે ટેબલ બીજી ટનલના રૂટ વહન કરે છે. રિવર્સ-પાથ ફિલ્ટરિંગ અહીં જાળ છે, કારણ કે ટેબલ જે ઇન્ટરફેસ પસંદ કરે તેના કરતાં અલગ ઇન્ટરફેસ પર આવતો જવાબ કાઢી નાખવામાં આવે છે, તેથી ટનલ તૂટેલી છે એવું નિષ્કર્ષ કાઢતા પહેલાં rp_filter સેટિંગ તપાસો.
ip rule add from 10.44.7.0/24 table 100
ip route add default dev tun1 table 100
sysctl net.ipv4.conf.all.rp_filter
નેટવર્ક નેમસ્પેસ સૌથી ભારે અને સૌથી સ્વચ્છ વિકલ્પ છે. બીજા ક્લાયન્ટને ip netns ની અંદર શરૂ કરો, તેને veth જોડી આપો, અને વાપરવા માટે તે નેમસ્પેસમાં પ્રવેશ કરો. દખલગીરી દૂર થાય છે કારણ કે દરેક નેમસ્પેસ એક ટેબલ વહેંચવાને બદલે પોતાના ટેબલ ધરાવે છે, જે બંને ટનલ અઠવાડિયાં સુધી ચાલુ રાખવી પડે ત્યારે વધારાની ગોઠવણને લાયક છે.
એપ્લિકેશન દીઠ, અને સાંકળ બનાવવી અલગ સમસ્યા તરીકે
કેટલીકવાર ફક્ત એક પ્રોગ્રામે બીજી ટનલ વાપરવી જોઈએ. લિનક્સમાં વપરાશકર્તા, cgroup કે પોર્ટ દ્વારા પોલિસી રૂટિંગ તે પરિણામ સુધી પહોંચે છે, અને એક લક્ષ્યને ડિફોલ્ટને સ્પર્શ્યા વિના ઇન્ટરફેસ સાથે પિન કરી શકાય છે. જે એપ્લિકેશન તેનું સોકેટ એક ઇન્ટરફેસ સાથે પિન કરે છે તે રૂટિંગ ટેબલને બિલકુલ પૂછતું નથી, તેથી લોન્ચર પોતાના સેટિંગમાં સરનામું પસંદ થાય ત્યાં સુધી ભૌતિક એડેપ્ટર વાપરવાનું ચાલુ રાખી શકે છે.
સાંકળ બનાવવી એ બે ટનલ સાથે ચલાવવાથી અલગ ક્રિયા છે. A ને B ઉપર સાંકળવાનો અર્થ છે કે આંતરિક સર્વરનું સરનામું બાહ્ય ટનલની અંદરથી પહોંચી શકાય તેવું હોવું જોઈએ. બાહ્ય ક્લાયન્ટે પણ આંતરિક ક્લાયન્ટના એન્ક્રિપ્ટેડ પેકેટને લીક ગણવા ન જોઈએ. વર્ચ્યુઅલ મશીનની અંદર એક ક્લાયન્ટ એ ઘરડી પણ વિશ્વસનીય આવૃત્તિ છે; એક જ હોસ્ટ પર બંને હોય તો ઉપરનું રૂટિંગ કામ વત્તા આંતરિક સર્વર તરફ બાહ્ય એવો માર્ગ જોઈએ જે ક્યારેય આંતરિક ટનલમાં પ્રવેશે નહીં.
ડિફોલ્ટનો માલિક, દરેક ટનલ વહન કરતું પ્રીફિક્સ યાદી અને DNS માર્ગ લખો. તે ત્રણ હકીકતો આગલી ઘટનાને તપાસને બદલે શોધમાં ફેરવે છે.