એપ-આધારિત vs ગંતવ્ય-આધારિત સ્પ્લિટ ટનલિંગ: કયું પસંદ કરવું

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

બે નિયમો જુદા જુદા સ્તરે કામ કરે છે

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

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

એપ નિયમો મોબાઇલ ક્લાયન્ટ અને સંચાલિત એજન્ટ માટે યોગ્ય છે

Android પસંદગી સીધી રજૂ કરે છે: VpnService.Builder.addAllowedApplication() અને addDisallowedApplication() પેકેજ નામ લે છે અને દરેક UID માટે નિર્ણય લાગુ કરે છે, જેમ Android ના VPN ડેવલપર માર્ગદર્શિકામાં વર્ણવ્યું છે. iOS માં બંડલ ઓળખકર્તા પર આધારિત પ્રતિ-એપ VPN નિયમો દ્વારા સમકક્ષ વ્યવસ્થા છે, જે સામાન્ય રીતે હાથે લખવાને બદલે MDM પ્રોફાઇલ દ્વારા અપાય છે.

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

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

ગંતવ્ય નિયમો સબનેટ સૂચિ અને સાઇટ પહોંચ માટે યોગ્ય છે

WireGuard મોડેલને સ્પષ્ટ કરે છે. AllowedIPs ક્રિપ્ટોકી રૂટિંગ છે: જે આંતરિક પેકેટનું ગંતવ્ય પીઅરની સૂચિમાં આવે છે તે તે પીઅર તરફ એન્ક્રિપ્ટ થાય છે, અને બાકીનું બધું સામાન્ય માર્ગે એન્ક્રિપ્શન વિના નીકળે છે. નામ આપવા જેવી કોઈ પ્રક્રિયા નથી અને શું સમાવિષ્ટ છે તેમાં કોઈ અસ્પષ્ટતા નથી.

OpenVPN ધકેલાયેલા રૂટિંગ ટેબલ દ્વારા એ જ સ્થાને પહોંચે છે. route-nopull સર્વરને રૂટ લાદવાથી રોકે છે, પછી ક્લાયન્ટ બાજુનું route 10.20.0.0 255.255.0.0 vpn_gateway બરાબર ઓફિસ પ્રીફિક્સ આવરી લે છે. IPv6 આ દરેક ક્લાયન્ટમાં અલગ વિધાન છે, અને તેને ભૂલી જવું એ સાચું દેખાતા IPv4 સ્પ્લિટની આસપાસ લીક થવાનો સૌથી સામાન્ય માર્ગ છે.

હોસ્ટનામ રૂટ નથી. જો પ્રોફાઇલ ડોમેન ક્ષેત્ર આપે, તો તેને ક્લાયન્ટ એક વાર ઉકેલે તેવા નામ તરીકે ગણો, કાયમી સરનામા શ્રેણી તરીકે નહીં; કન્ટેન્ટ ડિલિવરી નેટવર્ક અને લોડ બેલેન્સર કાલે અલગ સરનામાં આપશે.

બંને મોડેલ ક્યાં તૂટે છે: સહાયકો, શેર્ડ સેવાઓ, રિઝોલ્વર

સહાયક પ્રક્રિયાઓ એપ નિયમો તોડે છે એ રીતે જે સર્વરની ખામી જેવું લાગે. બ્રાઉઝરનું અપડેટર, ક્રેશ રિપોર્ટર, SYSTEM તરીકે ચાલતી સિંક સેવા અને બીજા પેકેજમાં જડિત WebView બધા અલગ ઓળખ છે, તેથી બ્રાઉઝર ટનલ કરવાથી ખરી વિનંતી ટનલની બહાર રહી શકે. ઊલટું પણ એટલું જ ગૂંચવણભર્યું છે: બહાર કાઢેલી એપ ટનલ કરેલી પ્રક્રિયાની અંદરની શેર્ડ લાઇબ્રેરી કૉલ કરે તો પણ તેનો ટ્રાફિક ટનલમાંથી જ જાય છે.

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

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

રનબુક: પસંદ કરો, લાગુ કરો, ચકાસો

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

તમે વ્યક્ત કરી શકો તે સૌથી સાંકડું સ્વરૂપ લાગુ કરો, પછી ક્લાયન્ટના સ્થિતિ ચિહ્નને નહીં પણ રૂટિંગ ટેબલને પૂછીને ચકાસો:

ip route get 10.20.30.40
ip -6 route get 2001:db8:10::40
wg show wg0 allowed-ips
Get-NetRoute -DestinationPrefix 10.20.0.0/16
Find-NetRoute -RemoteIPAddress 10.20.30.40

પ્રથમ બે લીટી સાચું ગંતવ્ય જે ઇન્ટરફેસ વાપરે તેનું નામ આપે છે; wg show ગોઠવેલી પ્રીફિક્સ સૂચિ છાપે છે; Windows પર Find-NetRoute પેકેટ મોકલતી વખતે સ્ટેક જે પ્રશ્નનો જવાબ આપશે તે જ પ્રશ્નનો જવાબ આપે છે. જો ઇન્ટરફેસ ટનલ હોય, તો નિયમ મેળ ખાધો.

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