Cloud VPN ની એ મર્યાદાઓ જે તમે ટ્યુન કરી શકતા નથી: IKE લાઇફટાઇમ અને પીઅર NAT

રિમોટ ઉપકરણને 24 કલાકનું ફેઝ 1 લાઇફટાઇમ આપો અને Cloud VPN ટનલ નીચે જ રહે છે, જોકે Google ની બાજુએ બધું બરાબર ગોઠવેલું હોય. પીઅર એવી કિંમત સૂચવે છે જે રિસ્પોન્ડર સ્વીકારશે નહીં, તેથી વાટાઘાટ કાં તો સંપૂર્ણ નિષ્ફળ જાય છે અથવા અનંત વાર ફરી શરૂ થાય છે. Cloud VPN ફેઝ 1 ને 36,000 સેકન્ડ સુધી મર્યાદિત કરે છે, એટલે કે દસ કલાક, અને આ મર્યાદા એવી સેટિંગ નથી જે તમે વધારી શકો. ફેરફાર રિમોટ ઉપકરણ પર જ કરવાનો છે.

પીઅર પૂછે છે, રિસ્પોન્ડર નક્કી કરે છે

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

કેસ ખોલતા પહેલાં ટનલની પોતાની સ્થિતિ વાંચો, કારણ કે વિગતવાર સ્થિતિ સામાન્ય રીતે નિષ્ફળ ગયેલો તબક્કો જણાવે છે:

gcloud compute vpn-tunnels describe office-tunnel \
  --region europe-west1 \
  --format="value(status,detailedStatus)"

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

36,000 સેકન્ડ એ ટોચની મર્યાદા છે

ફેઝ 1 36,000 સેકન્ડ પર અટકે છે. 86,400 પર ગોઠવેલું ઉપકરણ એવું કંઈક માંગે છે જેને રિસ્પોન્ડર કદી સ્વીકારશે નહીં, અને ફરી પ્રયાસ કરવાથી તેનો મત બદલાતો નથી. રિમોટ પ્રસ્તાવને મર્યાદામાં પાછો લાવો અને એ જ ગોઠવણી સ્થપાય છે; આ અસમાનતા એ જ આખો પાઠ છે, કારણ કે તમે તમારી કિંમત ઘટાડી શકો છો અને Google ની કિંમત વધારી શકતા નથી.

પસંદ કરેલી કિંમત ડિઝાઇન નોંધમાં લખો. નહીં તો આગામી એન્જિનિયર 24 કલાકનો પ્રયોગ ફરી કરશે અને એ જ દીવાલે પહોંચશે.

સમર્થિત સમૂહ દરેક ગેટવે પ્રકાર અને IKE આવૃત્તિ મુજબ પ્રકાશિત થાય છે Cloud VPN વિહંગાવલોકનમાં, તેથી સામાન્ય IKE માર્ગદર્શિકાને બદલે તમારા ટોપોલોજીનો વિભાગ વાંચો.

સમયપત્રક મુજબ પડતી ટનલ

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

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

સમૂહો ગેટવે પ્રકારમાંથી આવે છે

સાઇફર અને ઇન્ટિગ્રિટી સમૂહો એ દરેક ટનલ માટેની પ્રોફાઇલ નથી જે તમે strongSwan જેમ ફેરવી શકો. તમે તેમને ગેટવે પ્રકાર અને IKE આવૃત્તિ દ્વારા પસંદ કરો છો, અને ન હોય તેવી પ્રોફાઇલ શોધવામાં એક બપોર વેડફાય છે.

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

પ્રતિ ઉપકરણ એક બાહ્ય સરનામું

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

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