જ્યારે openfortivpn જોડાય ત્યારે રૂટ અને DNS નો માલિક કોણ હોવું જોઈએ?

કાર્યકારી openfortivpn સત્રમાં ચાર તબક્કા એકબીજા પર થર થાય છે. ક્લાયન્ટ ગેટવે પર પ્રમાણિત કરે છે અને TLS જોડાણ શરૂ કરે છે, પછી તે જોડાણની અંદર PPP ચલાવે છે, પછી સરનામું અને DNS માહિતી મેળવે છે, અને અંતે હોસ્ટ રૂટ અને રિઝોલ્વર સેટિંગ્સ લાગુ કરે છે. દરેક તબક્કો જીવંત હોઈ શકે છે જ્યારે આગળનો ન હોય, અને તેથી સપોર્ટ થ્રેડમાં “જોડાયેલ” એટલું લપસણો શબ્દ છે.

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

એક જ જોડાણ જેવા દેખાતા ચાર તબક્કા

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

બીજો તબક્કો PPP લિંક છે. ક્લાયન્ટ ટનલ ઉપકરણ સામે PPP પ્રક્રિયા શરૂ કરે છે, અને બંને બાજુઓ લિંક વિકલ્પો અને સરનામાં પર વાટાઘાટ કરે છે. તે પછી જ હોસ્ટ જાણે છે કે સત્ર કયા સ્થાનિક અને દૂરના સરનામાં વાપરે છે, અને ત્યારે જ ટનલ તરફ સંકેત કરતો રૂટ અર્થપૂર્ણ બની શકે છે.

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

રૂટિંગ કોષ્ટક કોણ સંપાદિત કરે છે

ડિફોલ્ટ રૂપે ક્લાયન્ટ માલિક છે. તે ભૌતિક ઇન્ટરફેસ દ્વારા ગેટવે તરફ રૂટ, ટનલના પીઅર માટે રૂટ, અને સત્રને વાપરવા મંજૂર હોય તેવા નેટવર્ક માટે રૂટ ઉમેરે છે, પછી પ્રક્રિયા બહાર નીકળે ત્યારે તેમને દૂર કરે છે. એ ડિફોલ્ટ એક જ નેટવર્ક મેનેજર ધરાવતા અને બીજું VPN સૉફ્ટવેર ન હોય તેવા લેપટોપ પર અનુકૂળ છે.

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

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

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

DNS અને રિઝોલ્વર ફાઇલનો માલિક કોણ છે

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

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

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

વિશેષાધિકાર, તૈયારી અને હેન્ડઓવર

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

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

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