OpenVPN રૂટ ડાયરેક્ટિવમાં વાઇલ્ડકાર્ડ કેમ કામ કરી શકતું નથી

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

રૂટ શું ઇન્સ્ટોલ કરે છે, અને શું ક્યારેય વાંચતું નથી

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

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

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

જ્યારે ગંતવ્ય ખરેખર ઉપસર્ગ હોય

જો લક્ષ્ય જાણીતું ખાનગી નેટવર્ક હોય, તો ઉપસર્ગ લખો. દસ્તાવેજીકરણ જગ્યાના ઉદાહરણ માટે, એક હોસ્ટ અને એક સબનેટ આ રીતે દેખાય છે:

route 10.60.4.20 255.255.255.255
route 10.60.0.0 255.255.0.0

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

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

જ્યારે કામનું એકમ હોસ્ટનામ હોય

ડોમેન દ્વારા પસંદ કરવા માટે ડોમેન વાંચે તેવું કંઈક જોઈએ, એટલે કે એપ્લિકેશન-સ્તરનો ઘટક. સામાન્ય જવાબ એ HTTP પ્રોક્સી છે જે ટનલની બીજી બાજુ રહે છે, અને ક્લાયન્ટ નક્કી કરે છે કે કઈ વિનંતીઓ તેને મોકલવી.

પ્રોક્સી કન્ફિગરેશન ફાઇલ તે પસંદગી વ્યક્ત કરી શકે છે. નીચેના ઉદાહરણના નિયમો એક ડોમેન અને તેના સબડોમેનને પ્રોક્સી પર અને બાકીનું બધું સીધું મોકલે છે:

function FindProxyForURL(url, host) {
    var h = host.toLowerCase();
    if (h === "corp.example" || dnsDomainIs(h, ".corp.example")) {
        return "PROXY 10.60.0.12:3128";
    }
    return "DIRECT";
}

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

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

પ્રોક્સી વિકલ્પ શું આવરી લેતો નથી

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

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

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

ફક્ત સુખી નહીં, બંને માર્ગોનું પરીક્ષણ

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

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