OPNsense પાછળ OpenVPN ક્લાયન્ટના સ્થિર સરનામાં

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

OPNsense એ ઓવરરાઇડ સર્વરની ક્લાયન્ટ-વિશિષ્ટ સેટિંગ્સમાં રાખે છે, પ્રમાણપત્રના કોમન નેમ દ્વારા કી કરેલી, જે કોમન નેમને સરનામા યોજનાનો ભાગ બનાવે છે.

ચીકણું લીઝ સ્થિર સરનામું નથી

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

ગતિશીલ વિકલ્પ, એટલે client-connect સ્ક્રિપ્ટ અને ગતિશીલ અપડેટ દ્વારા VPN ને DNS સાથે જોડવું, કામ કરે છે અને એવા રિઝોલ્વરની જરૂર છે જે અપડેટ સ્વીકારે, સાથે દરેક કનેક્શન પર એક સ્ક્રિપ્ટ. ઉપકરણ પર તમે વેન્ડર પૂરા પાડે તે પેકેજ સુધી મર્યાદિત છો, અને સામાન્ય રીતે ત્યાં જ એ યોજના અટકે છે.

એ /30 ગણિત જેનો કોઈ આનંદ લેતું નથી

ડિફોલ્ટ net30 ટોપોલોજીમાં, દરેક ક્લાયન્ટને પોતાનું /30 મળે છે: પ્રથમ વપરાયોગ્ય સરનામું સર્વર બાજુ જાય છે, બીજું ક્લાયન્ટને. તેથી ઓવરરાઇડ સર્વરના ગતિશીલ ટનલ નેટવર્કની બહાર હોવા જોઈએ, એટલે પહેલા એ નેટવર્ક પહોળું કરવું પડે. 10.8.0.0/24 પરનું સર્વર 10.8.0.0/23 પર જઈ શકે છે, જૂની શ્રેણીનો અડધો ભાગ ગતિશીલ ક્લાયન્ટ માટે અને બીજો અડધો ઓવરરાઇડ માટે રાખીને. મૂળ /24 ને વધારાના IPv4 સ્થાનિક નેટવર્ક તરીકે ઉમેરો જેથી બંને અડધા ભાગનું ટ્રાફિક ટનલમાં રૂટ થાય.

દરેક ઓવરરાઇડ સરનામું /30 સીમા પર પડવું જોઈએ, તેથી છેલ્લો ઓક્ટેટ ચારનો ગુણક હોય છે. 10.8.1.0 પરનું /30 ક્લાયન્ટને 10.8.1.2 આપે છે, અને DNS રેકોર્ડ એ જ સરનામું ધરાવે છે. તેના બદલે 10.8.1.3 પસંદ કરવાથી એવો ક્લાયન્ટ મળે છે જે જોડાય છે પણ ટ્રાફિક પસાર કરી શકતો નથી, કારણ કે સરનામું એવા સબનેટનું છે જે ટોપોલોજીએ તેને ક્યારેય સોંપ્યું નથી.

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

સ્થાનિક નેટવર્ક અને જે ઝોન ક્લાયન્ટ પૂછે છે

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

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

નવા જોડાણ પર શું તપાસવું

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

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