Access Server ગેટવે વપરાશકર્તા: ક્લાયન્ટની શાખા LAN નું રાઉટિંગ

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

બે સરનામાં, બે અલગ માલિકીના દાવા

ક્લાયન્ટ જોડાય ત્યારે Access Server તેને ગોઠવેલા VPN પૂલમાંથી સરનામું આપે છે, ઉદાહરણ તરીકે 10.90.0.0/24. એ ફાળવણી એક હોસ્ટ માટેની લીઝ છે. જોડાણમાં એવું કંઈ નથી કહેતું કે એ જ ક્લાયન્ટ 10.60.0.0/24ની સામે પણ છે, અને સર્વર અનુમાન કરશે નહીં: LAN પ્રીફિક્સ ચોક્કસ ક્લાયન્ટ દ્વારા ત્યારે જ પહોંચી શકાય છે જ્યારે વ્યવસ્થાપક તેને જાહેર કરે.

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

ગેટવે સેટિંગ ખરેખર શું સ્થાપિત કરે છે

Admin Web UI માં જાહેરાત એ વપરાશકર્તાની મિલકત છે: કનેક્ટર વપરાશકર્તા પર Configure VPN gateway સક્રિય કરો અને શાખાનું ખરેખરું પ્રીફિક્સ Network on the VPN client side માં દાખલ કરો. એ વપરાશકર્તા બીજા બધાની જેમ પ્રમાણિત થાય છે, તેથી તેને દેખરેખ વિનાના ઉપકરણ માટે યોગ્ય ઓળખપત્ર નીતિ જોઈએ છે, અને તેની સ્વયં-લોગિન પ્રોફાઇલ સુવિધાની ફાઇલ નહીં પણ ગુપ્ત છે.

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

બનાવેલી ફાઇલમાં પેસ્ટ કરેલી Community શ່લીની સૂચના આ મોડેલમાં ભાગ લેતી નથી. ઉત્પાદન પોતે મોકલાતા રૂટિંગ કોષ્ટકનું માલિક છે; હાથે સંપાદિત લીટી આગલી પેઢીમાં ફરી લખાય છે અથવા અવગણવામાં આવે છે.

બંને નેટવર્કના પરત માર્ગો પૂરા કરો

ચોક્કસ યોજના: મુખ્ય કાર્યાલય 10.40.0.0/24, શાખા 10.60.0.0/24, VPN પૂલ 10.90.0.0/24, અને Access Server મુખ્ય કાર્યાલયની બાજુએ ખાગલી સરનામા પર ઉપલ્બધ. મુખ્ય કાર્યાલયના રાઉટરને શાખાના પ્રીફિક્સ અને પૂલ માટે રૂટ જોઈએ છે, બંને Access Server તરફ. તેમના વિના ટનલ વિનંતી લઈ જાય છે અને જવાબ ડિફોલ્ટ ગેટવે થીને નીકળે છે, જે પરિચિત અધુરું-ખુલ્લું જોડાણ બનાવે છે.

શાખામાં કનેક્ટરે પોતાને સંબોધિત ન હોય તેવા પેકેટ આગળ મોકલવા જોઈએ છે: તેના ઓપરેટિંગ સિસ્ટમમાં IP ફોરવર્ડિંગ અને ટનલ તથા LAN ઇન્ટરફેસ સુધી મર્યાદિત ફોરવર્ડિંગ પરવાનગી; Linux પર net.ipv4.ip_forward=1 ફોરવર્ડ ચેઇન નિયમો સાથે, Windows પર routing and remote access. પછી શાખાના હોસ્ટને પરત માર્ગ જોઈએ છે: કાંતો કનેક્ટર તેમનો ડિફોલ્ટ ગેટવે છે, અથવા હાલનો ગેટવે મુખ્ય કાર્યાલય અને પૂલના પ્રીફિક્સ માટે ચોક્કસ રૂટ લે છે.

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

નિષ્ફળતાને માર્ગ તરીકે વાંચો, પરવાનગી તરીકે નહીં

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

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

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

Access Server site-to-site ટ્યુટોરિયલ એ જ સેટિંગ ઉત્પાદન ક્રમમાં સૂચવે છે; તમારા પોતાના પ્રીફિક્સમાં ડિઝાઇન ગોઠવતા પહેલા એક વાર અનુસરવા જેવું છે.