OpenVPN ક્લાયન્ટ્સ ગેટવેના IPsec સિલેક્ટર્સ કેમ ચૂકી જાય છે

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

ગેટવેનો ping એવો પ્રવાહ ચકાસે છે જે તમારો ક્લાયન્ટ ક્યારેય વાપરતો નથી

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

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

એ દૂરનો પ્રીફિક્સ પુશ કરો જે એપ્લિકેશનને ખરેખર જોઈએ છે

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

જે Community સર્વર પુશ કરેલા રૂટ સ્વીકારે છે ત્યાં નિર્દેશ ખરું માસ્ક લે છે: push "route 172.30.239.0 255.255.255.128". Access Server એ જ લક્ષ્યને ઇન્સ્ટોલ કરેલી આવૃત્તિની પ્રાઇવેટ-નેટવર્ક કે એક્સેસ-રૂલ સેટિંગ્સ દ્વારા ગોઠવે છે, અને રાઉટેડ કે અનુવાદિત મોડ સભાનપણે પસંદ કરાય છે. માલિક કન્ફિગરેશનને બદલે જનરેટ થયેલી ફાયરવોલ ચેઇન સંપાદિત કરવી એ જ રીતે કાર્યરત સેટઅપ પુનઃઉત્પાદન કરવું અશક્ય બને છે.

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

સિલેક્ટર્સમાં ક્લાયન્ટ પૂલનો સમાવેશ કરો

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

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

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

જાણી જોઈને રૂટિંગ કે અનુવાદ પસંદ કરો

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

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

ફોરવર્ડિંગ અને જવાબ પર લૂપ બંધ કરો

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

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

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