એક જ સર્વર IP, બે માર્ગ: OpenVPN ના બાહ્ય પ્રવાહને ચિહ્નિત કરવો

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

જે બે પ્રવાહને અલગ કરવા છે તેનાથી શરૂ કરો

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

આ વર્ણનમાં ધારો કે 10.90.0.10 પરનું ક્લાયન્ટ tun1 દ્વારા જોડાયેલું છે, સર્વરનું જાહેર સરનામું 198.51.100.25 છે, અને મુખ્ય કોષ્ટક અસ્પૃષ્ટ છે જેનો ડિફોલ્ટ માર્ગ સામાન્ય અપલિંક તરફ જાય છે. સર્વરની બાજુએ પણ આંતરિક માર્ગ પર વેબ સેવા સ્વીકારવી પડે છે અને ટ્રાફિક ટનલ સ્ત્રોત તરફ પાછો મોકલવો પડે છે; જાહેર સરનામે પેકેટ મોકલવું સર્વરના લિસનર કે ફાયરવોલ નીતિને રદ નથી કરતું.

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

પરબિડીયું વહન કરતી સોકેટને ચિહ્નિત કરો

ક્લાયન્ટ રૂપરેખાંકનને તેના એન્ક્રિપ્ટેડ બહાર જતા પેકેટ માટે ચિહ્ન મળે છે અને તે પોતે માર્ગ સ્થાપિત કરવાનું બંધ કરે છે, જેથી અવેજી નીતિ જ માર્ગ નક્કી કરતી એકમાત્ર વસ્તુ હોય:

mark 42
route-noexec
disable-dco

દશાંશ 42 એ હેક્સાડેસિમલ 0x2a છે, અને હેક્સ સ્વરૂપ એ જ છે જેની સાથે રાઉટિંગ નિયમો મેળ ખાશે. link-options નો સંદર્ભ mark ને Linux પર એન્ક્રિપ્ટેડ બહાર જતા પેકેટ પર લાગુ થતી વસ્તુ તરીકે વર્ણવે છે, એટલે કે બરાબર એ જ સોકેટ જેનો માર્ગ તમારે નિયંત્રિત કરવો છે. ડેટા ચેનલનું ઓફલોડ બંધ કરવાથી આ ઉદાહરણ વપરાશકર્તા-જગત માર્ગ પર રહે છે, જ્યાં ચિહ્નનું વર્તન વર્ણવેલું છે.

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

આ કરતી વખતે 198.51.100.25 માટે મુખ્ય કોષ્ટકમાં હોસ્ટ માર્ગ ન રાખો. આવો માર્ગ એ જ મુક્તિ પાછી લાવે છે જેને ડિઝાઇન સાંકડી કરવા માંગે છે, અને નીચેની કોઈપણ નીતિને પૂછવામાં આવે તે પહેલાં તે HTTPS પ્રવાહ માટે જીતી જશે.

બાકીનું બધું ટનલ કોષ્ટકમાં મોકલો

ટનલ ઇન્ટરફેસ અસ્તિત્વમાં આવે અને તેનું સરનામું ધરાવે ત્યારે નીતિ આવી દેખાય છે:

ip -4 route add default dev tun1 src 10.90.0.10 table 47100
ip -4 rule add priority 20000 lookup main suppress_prefixlength 0
ip -4 rule add priority 20001 not fwmark 0x2a lookup 47100
ip -4 rule add priority 20002 not fwmark 0x2a unreachable

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

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

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

પાછા ફરવાના માર્ગને એ જ ચિહ્ન દેખાવા દો

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

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

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

બે માર્ગ શોધથી આ સાબિત કરો

કર્નલ બે સંદર્ભો માટે શું નક્કી કરે તેની તુલના કરો, અને નિકાસ સ્થિતિને બદલે dev અને src ક્ષેત્રો વાંચો:

ip -4 route get 198.51.100.25
ip -4 route get 198.51.100.25 mark 0x2a

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

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