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

ટનલ ક્યાંથી શરૂ થવી જોઈએ

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

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

તમે ડાયલ કરો છો તે સરનામું અને મેળવો છો તે ઓળખને અલગ કરો

હબને શોધી શકાય તેવી સ્થિર વસ્તુ જોઈએ, મંજૂર નિશ્ચિત સરનામું અથવા જાળવાયેલું હોસ્ટનામ. શાખાને ઓળખાવા માટે સ્થિર રીત જોઈએ, અને IKEv2 માં તે ઓળખ પેલોડ છે જે તે પ્રમાણીકરણ દરમિયાન રજૂ કરે છે, તેના પેકેટો સાથે આવતા સ્રોત સરનામાથી સ્વતંત્ર. @branch-a.vpn.example જેવી શ્રેણી મોબાઇલ સરનામું દર કલાકે બદલાતું હોવા છતાં તે ઓળખ તરીકે કામ કરે છે.

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

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

હબની બાજુને નામવાળા પીઅર તરીકે લખો

strongSwan ની શબ્દાવલીમાં રિસ્પોન્ડર બાજુ એ right=%any ધરાવતું જોડાણ છે, જે કોઈ પણ સ્રોત સરનામેથી પીઅર સ્વીકારે છે, ઉપરાંત [email protected], જે તે પીઅરે પોતાને શું ગણાવવું જોઈએ તે પિન કરે છે. શાખાના LAN માટે rightsubnet=10.20.0.0/16, જોડાણ ડાયલ કર્યા વિના લોડ થાય તે માટે auto=add, જીવંતતા માટે dpd_delay=30s, અને સરનામા ફેરફારને નવા પીઅર તરીકે ગણવાને બદલે શોષી લેવા માટે mobike=yes ઉમેરો.

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

શાખાને આરંભક રાખો

શાખા પર અરીસાની છબી લાગુ પડે છે: સ્થાનિક મોબાઇલ સરનામું હાલ જેવું છે તેવું વપરાય તે માટે left=%defaultroute, ઓળખ રજૂ કરવા [email protected], સ્થિર હબ નામ માટે right=hub.example.com, અને માણસ વિના ટનલ ઉપર આવે તે માટે auto=start. જ્યારે મોબાઇલ લિંક ફરી જોડાય છે, શાખા ફરી આરંભે છે અને હબ એ જ ઓળખને એ જ નીતિ ઑબ્જેક્ટ સામે મેળવે છે.

બંને બાજુ UDP 500 પર IKE, UDP 4500 પર NAT ટ્રાવર્સલ, અને તેના પછી આવતા એન્કેપ્સ્યુલેટેડ ESP ની પરવાનગી આપો. પછી તેમને પરવાનગી આપેલા રાખો: ફક્ત ઓફિસ સમય દરમિયાન ખૂલતો નિયમ અવિરત ટનલ જેવો દેખાશે.

સરનામા ફેરફાર ચકાસો, ફક્ત પ્રથમ હેન્ડશેક નહીં

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

પછી સંરક્ષિત સબનેટ અલગથી તપાસો. સ્થપિત SA કહે છે કે પીઅરોએ પ્રમાણીકરણ કર્યું; તે એ નથી કહેતું કે હબ પાસે શાખાના LAN સુધીનો માર્ગ છે અથવા શાખા હબની બાજુથી ટ્રાફિક સ્વીકારે છે. રાઉટિંગ કોષ્ટક અને ફાયરવોલ નીતિ અલગથી વાંચો, પછી ગેટવેથી નહીં પણ હોસ્ટથી ping મોકલો, કારણ કે ગેટવે કોઈ પણ નેટવર્કનું સૌથી ઓછું પ્રતિનિધિત્વ ધરાવતું ઉપકરણ છે.

સ્થિર ઓળખ શાખાને એવા નીતિ ઑબ્જેક્ટમાં ફેરવે છે જેને હબ નામ આપી શકે. તે ઓપરેટર-NAT સરનામાને પહોંચી શકાય તેવું બનાવતું નથી, અને તે પોતાના આપ સંસ્થાના બાકીના ભાગને શાખામાં પ્રવેશ આપતું નથી.

સંબંધિત લેખો