શું એક WAN ઇન્ટરફેસ સાઇટ-ટુ-સાઇટ અને રિમોટ VPN બંને સેવા આપી શકે?

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

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

કોઈપણ રૂપરેખાંકન પહેલાં બે રેકોર્ડ

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

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

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

પીઅર મેચિંગ અને પ્રમાણીકરણ ક્યાં અલગ પડે છે

IOS XE પર IKEv2 પ્રોફાઇલ એ પરિમાણો લઈ જાય છે જેની વાટાઘાટ થઈ શકતી નથી, અને પીઅર પસંદ કરવા વપરાતી શરતો પણ. એટલે કે શાખાની બાજુ અને રોમિંગની બાજુ બંનેને પોતાની પ્રોફાઇલ જોઈએ, ભલે તેઓ એક જ ઇન્ટરફેસ પર પૂરા થાય અને ભલે એક જ ક્રિપ્ટો PKI વહેંચે. Cisco એ પ્રોફાઇલ, પ્રમાણીકરણ અને મેચિંગની ભૂમિકાઓ તેના IOS XE 17 માટેના IKEv2 રૂપરેખાંકન માર્ગદર્શિકામાં.

શાખાની પ્રોફાઇલ સામાન્ય રીતે સાંકડી ઓળખ સાથે મેળ ખાય છે: દૂરનું સરનામું, FQDN, કે સર્ટિફિકેટ સબ્જેક્ટ. match identity remote address 198.51.100.10 255.255.255.255 જેવું કંઈક એક પીઅરને પિન કરે છે, અને દરેક સાઇટ માટે સંગ્રહિત ચાવી સાથે authentication remote pre-share પૂરતું છે. મેચિંગને પીઅર યાદી પરવાનગી આપે તેટલું ચોક્કસ રાખો, કારણ કે પસંદગી ક્રમમાં ઉપર રહેલું ઓવરલેપિંગ વાઇલ્ડકાર્ડ શાખાનું ટ્રાફિક ખોટી પ્રોફાઇલમાં ખેંચી શકે છે.

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

ફોરવર્ડિંગ અને અનુવાદને પણ એ જ વિભાજન જોઈએ

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

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

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

ક્રોસ થયેલી નીતિ ઉજાગર કરતા સ્વીકૃતિ કિસ્સા

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

પછી રૂપરેખાંકન નહીં, ડેટા પ્લેન ચકાસો. show crypto ikev2 sa અને show crypto ipsec sa કહે છે કે કઈ પ્રોફાઇલ અને કયા સિલેક્ટરે દરેક ફ્લો વહન કર્યો, જ્યારે show ip nat translations અને ટનલ કાઉન્ટર બતાવે છે કે પરત માર્ગ અને મુક્તિ ખરેખર મળ્યાં કે નહીં. ટનલ ઇન્ટરફેસ પર tracer કે પેકેટ કેપ્ચર લૂપ બંધ કરે છે.

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