ડિફૉલ્ટ રીતે AWS Site-to-Site VPN એ રાહ જુએ છે કે customer gateway નેગોશિએશન શરૂ કરે. એ ડિફૉલ્ટ એક સેટિંગ છે, કાયદો નહીં, અને સેટિંગનું નામ Startup action છે. તેનો ઉપયોગ કરતાં પહેલાં બે પ્રશ્નો અલગ કરો જે સતત ભળી જાય છે: ટનલ કોણ ઊભી કરે છે, અને તમને જરૂરી પેકેટનો તેમાંથી પસાર થતો રૂટ છે કે નહીં. ફક્ત પહેલો જ ટનલના વિકલ્પોમાં રહે છે.

શરૂઆતની ક્રિયાને DPD ટાઇમઆઉટ ક્રિયાથી અલગ કરો

દરેક ટનલ માટેના બે વિકલ્પો બે જુદી ઘટનાઓ નિયંત્રિત કરે છે, અને એક સેટ કરવાથી બીજા વિશે કંઈ કહેવાતું નથી.

EventOptionUseful values
A new or modified VPN connection needs a tunnelStartup actionadd waits for the peer; start asks AWS to initiate
Dead peer detection times outDPD timeout actionclear ends the session, restart reinitiates, none does nothing

જો AWS એ નવી કે બદલાયેલી ટનલ ઊભી કરવી હોય, તો પસંદ કરો start. જો AWS એ DPD ટાઇમઆઉટ પછી નેગોશિએશન પણ ફરી શરૂ કરવું હોય, તો તે ઘટના માટે અલગથી restart ગોઠવો. બંનેમાંથી કોઈ વિકલ્પ એપ્લિકેશનની રિટ્રાય નીતિ નથી, અને કોઈ પણ રીકી ઇન્ટરવલ નથી: DPD તપાસે છે કે પીઅર જીવંત છે કે નહીં, જ્યારે રીકીંગ ચાલુ ટનલ પર security associations બદલે છે.

ટનલ હજી up દર્શાવે છે ત્યારે ટાઇમઆઉટ થતી એપ્લિકેશનની સમસ્યા ડેટા-પાથમાં છે. DPD ટાઇમર ટૂંકો કરવાથી તે સુધરશે નહીં, અને તે ઉપદ્રવ ઉમેરી શકે છે જે તમારે પછી સમજાવવો પડશે.

તપાસો કે AWS પાસે નેગોશિએશન મોકલવાનું સ્થાન છે

AWS તરફથી શરૂઆત ફક્ત IKEv2 સાથે જ થાય છે, અને પ્રસ્તાવ ક્યાં મોકલવો તે જાણવા AWS ને customer gateway નું જાહેર સરનામું જોઈએ છે. જે કિસ્સો સૌથી વધુ દુખે છે તે સરનામા વિના બનાવેલું સર્ટિફિકેટ-ઓથેન્ટિકેટેડ customer gateway રિસોર્સ છે: AWS નું દસ્તાવેજીકરણ સરનામા સાથે નવું customer gateway રિસોર્સ બનાવવાનું અને પછી VPN કનેક્શનને તે તરફ નિર્દેશિત કરવા બદલવાનું કહે છે.

સર્ટિફિકેટ સાબિત કરે છે કે પીઅર કોણ છે. તે AWS ને જણાવતું નથી કે પીઅર ક્યાં છે, અને આ બે જુદી આવશ્યકતાઓ છે. તેથી ઉપાય નવું સર્ટિફિકેટ નહીં પણ નવું customer gateway રિસોર્સ છે. સર્ટિફિકેટ બદલવાથી AWS પાસે એ જ ખૂટતું લક્ષ્ય રહે છે.

જો customer gateway NAT પાછળ હોય, તો AWS ને ગોઠવેલું responder identity પણ જોઈએ, IDr, જેથી પીઅરની ઓળખ ઉપકરણ જે ધારે છે તેની સાથે મેળ ખાય. તમે હમણાં બદલેલા વિકલ્પને દોષ આપતાં પહેલાં એ મૂલ્ય અને IKE ટ્રાફિક પસાર થવા દેતો ફાયરવૉલ માર્ગ ખાતરી કરો. start પસંદ કરવાથી અપ્રાપ્ય કે ખોટી ઓળખાયેલા પીઅરને પ્રસ્તાવ સ્વીકારવા મજબૂર કરી શકાતું નથી.

ફેરફાર એક ટનલ પર લાગુ કરો અને વિક્ષેપની અપેક્ષા રાખો

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

  1. Site-to-Site VPN કનેક્શન પસંદ કરો અને Modify VPN tunnel options ખોલો.
  2. બહારના IP સરનામા દ્વારા ટનલ પસંદ કરો અને તેની IKE આવૃત્તિ અને customer gateway રિસોર્સ ખાતરી કરો.
  3. તમે ખરેખર ઇચ્છો છો તે શરૂઆત અને DPD ક્રિયાઓ ગોઠવો, પછી તમારા નિયંત્રણ હેઠળના સમયગાળામાં સાચવો.
  4. ખાતરી કરો કે બદલાયેલી ટનલ સ્થપાય છે, અને આગળના ફેરફાર પહેલાં બીજી ટનલ અને રૂટિંગ તપાસો.

જાળવણી પહેલાં એક વર્તન ધ્યાન આપવા લાયક છે. AWS શરૂઆત સક્રિય હોય ત્યારે કોઈ ટાઇમઆઉટ નથી: ટનલ ઊભી થાય ત્યાં સુધી AWS પ્રયાસ કરતું રહે છે, અને customer gateway delete-SA સંદેશ મોકલે ત્યારે ફરી શરૂ કરે છે. જો તમે પીઅરને જાણી જોઈને બંધ કરો, તો AWS ટકોરા મારતું રહેશે, અને પીઅરના લોગ તે દર્શાવશે.

ફક્ત ટનલની સ્થિતિ નહીં, એપ્લિકેશનનો માર્ગ ચકાસો

ટનલ up દર્શાવે એટલે કામ કરતી વિનંતી નહીં. VPC સાથે જોડાયેલા Lambda ફંક્શનને હજી ગ્રાહકના પ્રીફિક્સ સુધીનો subnet રૂટ, ટ્રાફિકની પરવાનગી આપતા security group અને network ACL નિયમો, સાચું સરનામું પરત આપતું નામ-નિરાકરણ, અને ગ્રાહકની બાજુએ પરત માર્ગની જરૂર છે.

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

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

સંબંધિત લેખો