Azure S2S VPN કનેક્ટેડ છે પણ ટ્રાફિક નથી: IKE લોગ વાંચો

પોર્ટલ Connected કહે છે, ટનલમાં અપટાઇમ કાઉન્ટર છે, અને તમારી વર્ચ્યુઅલ મશીનમાંથી એક trace બીજા હોપ પર મરી જાય છે. કનેક્શનની સ્થિતિ IKE અને IPsec વાટાઘાટનું વર્ણન કરે છે, બંને બાજુઓની પોલિસી સ્તરમાંથી એક પેકેટ પસાર થાય છે કે નહીં તે નહીં. બે ખામીઓ આમાંની મોટાભાગની ટિકિટો સમજાવે છે, અને એક પણ Azure રૂટ બદલવાથી સુધરતી નથી. બંને પહેલેથી જ ગેટવેએ બનાવેલા લોગમાં લખાયેલી છે, એટલે હું રૂટ ટેબલમાંથી નહીં, ત્યાંથી શરૂ કરું છું.

Connected ખરેખર શું પ્રમાણિત કરે છે

કનેક્ટેડ site-to-site કનેક્શનનો અર્થ છે કે ફેઝ 1 અને ફેઝ 2 પૂર્ણ થયા અને સિક્યુરિટી એસોસિએશન સક્રિય છે. આ વાટાઘાટ વિશેનું વિધાન છે: બંને પીઅર એક પ્રસ્તાવ પર સંમત થયા, કી બદલી અને SA જોડી ઇન્સ્ટોલ કરી. તમે જે સબનેટને સુરક્ષિત માનો છો તેની સાથે ટ્રાફિક સિલેક્ટર મળે છે કે નહીં, અથવા ડિક્રિપ્ટ કર્યા પછી દૂરની બાજુ પેકેટને ક્યાંય રૂટ કરશે કે નહીં, તે વિશે તે કંઈ કહેતું નથી. ટનલ અઠવાડિયાં સુધી ચાલુ રહી શકે છે જ્યારે દરેક રસપ્રદ ફ્લો છોડી દે છે, અને આ જ તે પેટર્ન છે જે લોકોને સ્વસ્થ ગેટવે ફરીથી બનાવવા મજબૂર કરે છે.

પહેલાં તપાસવા લાયક બે ખામીઓ એ છે કે પીઅર ESP ને બદલે AH પ્રસ્તાવ કરે છે, અને વર્ચ્યુઅલ નેટવર્ક એવી જગ્યામાં નંબર કરેલું છે જેને ગેટવે આંતરિક નહીં ગણે.

રૂટને અડકતા પહેલાં એક્સપોર્ટ કરેલો લોગ ખોલો

પોર્ટલમાં વર્ચ્યુઅલ નેટવર્ક ગેટવે ખોલો અને કનેક્શન પર VPN troubleshoot કામગીરી ચલાવો, પછી તે જે બંડલ બનાવે છે તે ડાઉનલોડ કરી અનપેક કરો. અંદર ફેઝ 1 અને ફેઝ 2 ના વિનિમય સાથેનો IKE લોગ છે, સમય-છાપ સાથે અને સાદા ટેક્સ્ટ તરીકે વાંચી શકાય તેવો. ઉપરથી નીચે વાંચવાને બદલે તેમાં transform લાઇન શોધો, કારણ કે રસપ્રદ એન્ટ્રી સામાન્ય રીતે થોડી સેંકડો લાઇન પછી હોય છે. જો પોર્ટલની ઍક્સેસ ન હોય, તો ડાયગ્નોસ્ટિક સેટિંગ્સ ચાલુ હોય ત્યારે એ જ ડાયગ્નોસ્ટિક્સ ગેટવેના લોગ ગંતવ્યમાં દેખાય છે.

બે એન્ટ્રીઓ મોટાભાગનું મૂલ્ય ધરાવે છે. પહેલી લગભગ આમ કહે છે: expected ESP with combined authentication and cipher, received AH. બીજી IKE વિનિમય દરમિયાન invalid payload ભૂલ છે, જેનો અર્થ સામાન્ય રીતે ખોટી રચાયેલું અથવા અસમર્થિત પ્રસ્તાવ ક્ષેત્ર છે.

બંને વર્ણવે છે કે ઓન-પ્રિમાઇઝ ઉપકરણે શું પ્રસ્તાવ કર્યો, એટલે બંને પીઅર બાજુની સેટિંગ્સ છે. કનેક્શનની Azure બાજુ ફરી બનાવવાથી તમારો ફાયરવોલ જે પ્રસ્તાવ મોકલે છે તે બદલાતો નથી, અને તેમ છતાં કરવું એ આ કાર્યપ્રવાહમાં સૌથી વધુ વેડફાતો કલાક છે. પીઅર પર ફેઝ 2 ને સંયુક્ત પ્રમાણીકરણ અને સાઇફર સાથે ESP પર સેટ કરો અને એલ્ગોરિધમ વાટાઘાટ કરવા દો, પછી તપાસો કે combined mode જેવા નામવાળું વેન્ડર ચેકબોક્સ નીચેથી ચૂપચાપ AH પ્રસ્તાવ પસંદ કરી રહ્યું છે કે નહીં.

વર્ચ્યુઅલ નેટવર્કની એડ્રેસ સ્પેસની પુષ્ટિ કરો

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

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

બંને દિશામાં પ્રીફિક્સ ચકાસો

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

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

ping નહીં, પાથ ચકાસો

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

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

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