સાઇટ-થી-સાઇટ VPN પર ASA DHCP રિલે: પગલાવાર માર્ગદર્શિકા

રિલે ત્રણ તબક્કામાં કામ કરે છે અને ફક્ત વચ્ચેનો તબક્કો જ VPN પાર કરે છે. ક્લાયન્ટ શાખા સેગમેન્ટ પર બ્રોડકાસ્ટ કરે છે, ASA તે બ્રોડકાસ્ટને DHCP સર્વર માટે યુનિકાસ્ટ વિનંતીમાં ફેરવે છે, અને સર્વર ક્લાયન્ટને બદલે રિલે સરનામાંને જવાબ આપે છે. આ ક્રમમાં તબક્કા પસાર કરો, અને «રિલે તૂટેલું છે» ના મોટા ભાગના કિસ્સા ગુમ થયેલી નીતિ અથવા ખોટી રીતે વંચાયેલી setroute લાઇન સુધી જ આવીને ઊભા રહે છે.

પ્રથમ તબક્કો: ક્લાયન્ટ તરફના ઇન્ટરફેસ પર રિલે સક્રિય કરો

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

કંઈપણ બદલતા પહેલાં ચાલુ કન્ફિગ તપાસો: કયા ઇન્ટરફેસ પર રિલે સક્રિય છે, કયું સર્વર સ્વરૂપ હાજર છે, અને setroute ક્લાયન્ટ ઇન્ટરફેસ સાથે જોડાયેલું છે કે નહીં. જો ASA બીજા સેગમેન્ટ માટે DHCP સર્વર પણ ચલાવે છે, તો થોભો અને પ્રતિબંધોની યાદી વાંચો; એક જ બોક્સ પર સર્વર અને રિલે બંને સક્રિય કરી શકાતા નથી.

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

બીજો તબક્કો: ASA દ્વારા ઉત્પન્ન થયેલો ટ્રાફિક ટનલ દ્વારા લઈ જાઓ

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

ખાતરી કરો કે રસપ્રદ ટ્રાફિક ASA ના રિલે સ્રોત અને સર્વરના સરનામાને આવરી લે છે, અને પાછળની દિશા પણ મંજૂર છે. VTI-આધારિત ડિઝાઇનમાં રાઉટિંગ નિર્ણય સરળ છે, પરંતુ VTI પર રિલે સપોર્ટ ચોક્કસ રિલીઝમાં આવ્યો હતો; ASA DHCP માર્ગદર્શિકા 9.14(1) દર્શાવે છે, તેથી જૂના ઉપકરણ પર VTI ઉદાહરણ કૉપિ કરતા પહેલાં ઇમેજ તપાસો.

ASA થી સર્વર સુધીનો ping પોતાનાથી થોડું જ સાબિત કરે છે. તે બીજા માર્ગે, બીજા સ્રોત-સરનામા સાથે, અથવા એવી નીતિ હેઠળ સફળ થઈ શકે છે જેની સાથે રિલેના પેકેટ મેળ ખાતા નથી.

ત્રીજો તબક્કો: જવાબ અને setroute વિકલ્પ વાંચો

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

પછી સરખા સંભળાતા બે વસ્તુઓને અલગ કરો. setroute કીવર્ડ ASA ક્લાયન્ટને આપતો ડિફૉલ્ટ-રાઉટર વિકલ્પ બદલે છે અથવા ઉમેરે છે. તે ASA પર કોઈ રૂટ ઇન્સ્ટૉલ કરતો નથી અને VPN નીતિ બનાવતો નથી. સરનામું મળ્યા પછી પણ ક્યાંય પહોંચી ન શકતા ક્લાયન્ટમાં ઘણી વાર setroute અથવા સ્કોપની સમસ્યા હોય છે, ટનલની નહીં. સ્થિર ગેટવે વગરના ક્લાયન્ટ સાથે તેની કસોટી કરો અને ઑફરમાં કયો ડિફૉલ્ટ રાઉટર દેખાય છે તે જુઓ.

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

તેને ઠીક થયું કહેતા પહેલાં હું શું તપાસું છું

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

જો કોઈ તબક્કો મૌન હોય, તો બીજું રિલે વિધાન ઉમેરવાને બદલે સંબંધિત નીતિ કે રૂટ તપાસો. કોઈ વ્યક્તિ એસ્કલેટ કરે ત્યાં સુધીમાં રિલે કન્ફિગ સામાન્ય રીતે સાચું જ હોય છે; જે બદલાયું છે તે ટનલ નીતિ કે પાછળનો રૂટ છે.

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