Cloud VPN ટનલ પર ક્યારેય Established સુધી પહોંચતું ન હોય તેવું BGP સત્ર સામાન્ય રીતે રાઉટિંગ સમસ્યા નથી. તે વાયરિંગની સમસ્યા છે: બે સરનામાં જે એકબીજાનું પ્રતિબિંબ હોવા જોઈએ તે ખોટા ક્રમમાં દાખલ થયાં હતાં, અથવા પહેલી ટનલની જોડી બીજી પર ફરી વપરાઈ હતી. ટનલ પોતે સંપૂર્ણ સ્વસ્થ હોઈ શકે જ્યારે સત્ર Waiting for peer પર બેઠું હોય, કારણ કે IPsec અને BGP એ જ બે અંત્યબિંદુઓ વચ્ચેની અલગ વાટાઘાટો છે. કંઈપણ ફરી બનાવતા પહેલાં નક્કી કરો કે આ બેમાંથી કયું તૂટેલું છે.

એક પ્રશ્ન મોટા ભાગના કિસ્સા ઉકેલે છે: શું પીઅર ઉપકરણ Cloud Router નું સરનામું જુએ છે ખરું?

ટનલની સ્થિતિ અને સત્રની સ્થિતિ અલગ તપાસ છે

પહેલાં IKE અને ESP આવે છે. જો ટનલ સ્થપાયેલી ન હોય, તો તેની અંદરનું કંઈ મહત્વનું નથી અને BGP સરનામાની ચર્ચા વહેલી છે. ટનલની સ્થિતિ અને વિગતવાર સ્થિતિ વાંચો, પછી તે જ ટનલ માટે રાઉટરની BGP પીઅર સ્થિતિ વાંચો.

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

દરેક ટનલને પોતાનું /30 જોઈએ, બંને છેડા ભરેલા હોવા જોઈએ

દરેક HA VPN ટનલને 169.254.0.0/16 માંથી link-local /30 મળે છે, એક સરનામું Cloud Router ઇન્ટરફેસ પર અને બીજું તમારા પીઅર પર. પીઅર ફીલ્ડે દૂરનો છેડો દર્શાવવો જોઈએ, કદી રાઉટરનું પોતાનું સરનામું નહીં.

બે ટનલ એટલે Cloud Router પર બે ઇન્ટરફેસ, દરેક અલગ /30 સાથે. ટનલ 0 ની જોડી ટનલ 1 પર ફરી વાપરવી એ ભૂલ છે જે સારાંશ કોષ્ટકમાં સુઘડ લાગે છે અને OPEN પેકેટમાં મરી જાય છે.

TunnelRouter interfacePeer addressWhat a swap produces
tunnel 0169.254.1.1/30169.254.1.2OPEN sent to itself or to nothing; session waits
tunnel 1169.254.1.5/30169.254.1.6same failure on the second session
bothone pair reusedone address reusedone session up, the other never leaves waiting

જોડી કન્સોલ સારાંશમાંથી નહીં, રાઉટર સ્રોતમાંથી વાંચો. સારાંશ પીઅર સરનામું એવા કૉલમમાં દર્શાવે છે જે ખોટું વાંચવું સહેલું છે, અને ઇન્ટરફેસનું ipRange તથા પીઅરનું peerIpAddress એક જ /30 ના વિરોધી છેડા વર્ણવવા જોઈએ.

અદલાબદલી સામાન્ય રીતે પુનર્નિર્માણ દરમિયાન થાય છે

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

કન્સોલ ખોલતા પહેલાં જોડીઓ લખી લો: ટનલનું નામ, ઇન્ટરફેસ, રાઉટર સરનામું, પીઅર સરનામું, પીઅર ASN. પછી બંને ટનલ એક જ વારમાં બનાવો, જેથી બીજી પહેલીના અવશેષોથી ન ભરાય.

સત્ર રાહ જોવાનાં બીજાં ત્રણ કારણો

પહેલું પીઅર ASN છે: દરેક બાજુ બીજી બાજુના ASN સાથે ગોઠવાયેલી હોવી જોઈએ, અને અસંગતિ પીઅર સુધી પહોંચે છે પણ ક્યારેય સ્થપાતી નથી. બીજું પીઅરનું પોતાનું ફાયરવોલ છે, જેણે ટનલ ઇન્ટરફેસ પર TCP 179 ને મંજૂરી આપવી પડે; IKE કે ESP નિયમ તેને આવરી લેતો નથી. ત્રીજું એવું પીઅર છે જે તેના પડોશી તરીકે ગોઠવાયેલા સરનામા કરતાં જુદા સ્રોત સરનામેથી જવાબ આપે છે.

પીઅરનું પોતાનું લોગ નિર્ણાયક છે. જો તેના BGP સારાંશમાં તે સરનામા માટે કોઈ પડોશી ન હોય, તો પેકેટ આવતાં નથી અને જોડી કે માર્ગ ખોટો છે. જો પડોશી Active કે Connect માં હોય, તો પેકેટ આવે છે અને સત્રના પરિમાણો મેળ ખાતા નથી.

પેકેટ જે ક્રમમાં મુસાફરી કરે તે ક્રમમાં ચકાસો

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

gcloud compute routers get-status ROUTER --region=REGION પીઅરની સ્થિતિને તે જે સરનામું વાપરે છે તેની બાજુમાં છાપે છે, અને એ જ તમારે સરખાવવાની જોડી છે.

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

સંબંધિત લેખો