ડાઉનસ્ટ્રીમ સબનેટ vs ડેસ્કટોપ VPN: ટ્રાન્ઝિટ બાકાત રાખો, એપ્સ નહીં
પ્રતિ-એપ્લિકેશન બાયપાસ ફક્ત સ્થાનિક આઉટપુટનું વર્ગીકરણ કરે છે. વર્કસ્ટેશન પાછળનાં ઉપકરણોને પોતાની ઇનગ્રેસ, ફોરવર્ડિંગ અને રિટર્ન-પાથ નીતિની જરૂર છે.
એક મશીન, બે કામ, એક ફાયરવોલ: એક Wi-Fi અપલિંક, તેની પાછળ નાનું Ethernet સબનેટ અને એક ડેસ્કટોપ VPN ક્લાયન્ટ જે ધારે છે કે મશીનમાંથી નીકળતું બધું સ્થાનિક છે. સ્થાનિક રીતે શરૂ કરેલી એપ્લિકેશનો સ્થાનિક આઉટપુટ પાથ દ્વારા નીકળે છે. વર્કસ્ટેશન પાછળનાં ઉપકરણો Ethernet પોર્ટ પર આવે છે અને ફોરવર્ડિંગ નિર્ણયની જરૂર છે. પહેલા પાથ માટે લખાયેલ બાકાત બીજાને ક્યારેય જોતું નથી, અને તેથી જ બ્રાઉઝર ટનલને ટાળે છે જ્યારે ઉપકરણો ટાળતાં નથી.
બે પેકેટ પાથ, એક નીતિ
| Origin | Path | Decision owner |
|---|---|---|
| Application on the workstation | OUTPUT then egress | The VPN app's routing policy |
| Device behind the workstation | PREROUTING then FORWARD | The workstation's own forwarding policy |
પહેલી હરોળ એ છે જે મોટાભાગની split-tunneling માર્ગદર્શિકાઓ વર્ણવે છે. બીજી એ રાઉટર રૂપરેખાંકન છે જે કોઈક રીતે એ જ મશીન પર રહે છે. બંનેને એક માનસિક મોડેલમાં ભેગા કરવા એ ભૂલ છે; તેઓ કર્નલ વહેંચે છે, નીતિ નહીં. કોઈપણ નિયમ સંપાદિત કરતાં પહેલાં બંને પાથ દોરો, અને બાકીની રચના કયો પાથ ખૂટે છે તેના પરથી આવે છે.
કોષ્ટક એ પણ સમજાવે છે કે એક મશીન એક પરીક્ષણ પાસ કરીને બીજામાં કેમ નિષ્ફળ જાય. વર્કસ્ટેશન પરનું બ્રાઉઝર સ્થાનિક પાથ સાબિત કરે છે; Ethernet પોર્ટમાં જોડાયેલું લેપટોપ ફોરવર્ડિંગ પાથ સાબિત કરે છે. દરેક ફેરફારને બંનેથી ચકાસો, નહીંતર બ્રાઉઝર કેટલી વાર પણ રિફ્રેશ થાય, બીજો અણચકાસાયેલો રહે છે.
એપ્લિકેશન બાકાત ખરેખર શું વર્ગીકૃત કરે છે
પ્રતિ-એપ્લિકેશન બાકાત સામાન્ય રીતે આ રીતે કામ કરે છે: પ્રોસેસ કે વપરાશકર્તાના પેકેટને માર્ક કરીને, અને પછી માર્ક કરેલ ટ્રાફિકને ટનલની બહાર રૂટ કરે છે. તે સ્થાનિક-આઉટપુટ રચના છે. ડાઉનસ્ટ્રીમ ઉપકરણના પેકેટમાં સ્થાનિક પ્રોસેસ હોતી નથી, તેથી તે સિલેક્ટર સાથે ક્યારેય મેળ ખાતું નથી, સિલેક્ટર ગમે તે હોય.
સિલેક્ટર ગમે તે હોય, બંને યાદીઓ એક જ યાદી નથી, અને આખો મુદ્દો એ જ છે. Mullvadની Linux માર્ગદર્શિકા તેના ફાયરવોલ અને રૂટિંગ નીતિ વાપરતા માર્કનું વર્ણન કરે છે, અને તેના ઉદાહરણો સ્થાનિક આઉટપુટને લક્ષ્ય બનાવે છે; તે ડાઉનસ્ટ્રીમ રાઉટરનું સમર્થિત વર્ણન નથી. તેમને કૉપિ કરવાથી એવું મશીન મળે છે જે માને છે કે તેની પાસે બાકાત છે, જ્યારે તે બધું ટનલમાં ફોરવર્ડ કરે છે.
ટ્રાન્ઝિટ કરાર લખો
ડાઉનસ્ટ્રીમ સ્રોત પ્રીફિક્સ અને ઇનગ્રેસ ઇન્ટરફેસને સાથે નામ આપો, પછી તે પ્રીફિક્સને ઇનગ્રેસ પર મર્યાદિત કરો. મર્યાદા વિના, પોર્ટ સુધી પહોંચતું કોઈપણ ઉપકરણ બાકાત કરેલું સરનામું દાવો કરીને બાયપાસ દ્વારા નીકળી શકે છે. તેને બે પ્રશ્નો તરીકે લો: શું આ હોસ્ટ આ અપલિંકનો બિલકુલ ઉપયોગ કરી શકે છે, અને શું તેઓ વર્કસ્ટેશન કે ટનલની ખાનગી શ્રેણીઓ સુધી પહોંચી શકે છે? તે વધારાની પરવાનગીઓ છે, અપલિંક પસંદગીની આડઅસર નહીં.
ફોરવર્ડિંગની પરવાનગી આપો, પછી તેને ફિલ્ટર કરો. Linux ગેટવેને ફોરવર્ડિંગ સક્ષમ, બંને દિશામાં ઇચ્છિત ટ્રાફિકની પરવાનગી આપતા નિયમો, અને કાં તો અપસ્ટ્રીમ રિટર્ન રૂટ કાં તો જાણી જોઈને મર્યાદિત સ્રોત અનુવાદની જરૂર છે. NAT એકલું અપલિંક પસંદ કરતું નથી અને ફિલ્ટરમાંથી પસાર થવા દેતું નથી; તે તે નિર્ણયો પછી ફક્ત સરનામું ફરી લખે છે.
ટ્રાન્ઝિટ માટે વર્ગીકરણ ફોરવર્ડિંગ રૂટ નિર્ણય પહેલાં થવું જોઈએ, એટલે કે output નહીં, prerouting તબક્કે. નિર્ણય પછી મૂકાયેલો નિયમ પેકેટ બદલી શકે છે, પણ પેકેટ પહેલેથી ક્યાં મોકલાયું છે તે બદલી શકતો નથી.
માર્ક તેના માલિક એપ્લિકેશનના છે
માર્ક મૂલ્યો, ટેબલ નંબર અને ચેઇન પ્રાયોરિટી VPN એપ્લિકેશનની નીતિનો ભાગ છે, શાશ્વત સ્થિરાંકો નહીં. જે નેટવર્ક બીજા પ્રોગ્રામ ફરી બનાવે તેવા ટેબલમાં નિયમ દાખલ કરવા પર આધાર રાખે છે, તે આગલા અપડેટમાં તૂટી પડશે, સામાન્ય રીતે પુનઃકનેક્શન દરમિયાન, અનુકૂળ સમયે નહીં.
accept ચુકાદા સાથે બીજી બેઝ ચેઇન ઉમેરવાથી પછીની ચેઇનનું drop આવશ્યકપણે રદ થતું નથી. બેઝ ચેઇનમાં હૂક અને પ્રાયોરિટી હોય છે, અને ક્રમમાં પહેલો ચુકાદો જીતે છે; એક ચેઇનમાં accept બીજી ચેઇન પહેલાં પહોંચતા dropને રદ કરતું નથી. સંપૂર્ણ નિયમસેટ અને રૂટિંગ નીતિનો ક્રમ જુઓ, વધેલા એક કાઉન્ટરને નહીં. કાઉન્ટર સાબિત કરે છે કે નિયમ ચાલ્યો, ક્યારેય નહીં કે તેનો ચુકાદો જ લાગુ થયો.
એકીકૃત કરો, અથવા સબનેટ ખસેડો
બંને રચનાઓમાં ફરક એ છે કે બાયપાસની માલિકી કોની છે. એકીકૃત રચના એક મશીન અને એક નીતિ રાખે છે, પણ તેની કિંમત VPN એપ્લિકેશનના ટેબલ જીવનચક્ર અને તેના દસ્તાવેજ બદલી શકે તેવા માર્ક સમૂહ પરની નિર્ભરતા છે. ડાઉનસ્ટ્રીમ નેટવર્ક માટે સમર્પિત રાઉટર તે નિર્ભરતા સંપૂર્ણપણે દૂર કરે છે: સબનેટનું પોતાનું અપલિંક હોય છે, અને વર્કસ્ટેશન ફોરવર્ડિંગ ભૂમિકા વગરનું ક્લાયન્ટ રહે છે.
બીજું પસંદ કરો જ્યારે ડાઉનસ્ટ્રીમ નેટવર્કને VPN અપડેટ્સ દરમિયાન કામ કરતું રહેવું હોય, અથવા જ્યારે દરેક પ્રકાશન પછી એકીકૃત નીતિ કોઈ પરીક્ષણ ન કરી શકે. પહેલું ફક્ત ત્યારે પસંદ કરો જ્યારે એકીકરણ દસ્તાવેજીકૃત હોય અને કોઈ તેનો જવાબદાર હોય.
ચાર સ્થિતિમાં સીમા ચકાસો: જોડાયેલ, ફરી જોડાતું, જાણી જોઈને અવરોધિત અને થોભાવેલ. દરેકમાં નામ-ઉકેલ અને બંને એડ્રેસ કુટુંબ તપાસો, કારણ કે DNS લીક કરતો બાયપાસ તમે રચેલી બાકાત નથી. પરીક્ષણે ચોક્કસ સીમા સાબિત કરવી જોઈએ, ફક્ત એક પૃષ્ઠ લોડ થયું તે નહીં.