د Cloud VPN هغه حدود چې تاسو یې نشئ تنظیمولی: د IKE عمر او د peer NAT

لرې وسیلې ته د 24 ساعتونو د 1 پړاو عمر ورکړئ او د Cloud VPN تونل به لاندې پاتې شي، حتی کله چې د Google په اړخ کې هر څه سم تنظیم شوي وي. Peer هغه ارزښت وړاندیز کوي چې ځواب ورکوونکی به یې ومني نه، نو مذاکره یا بشپړه ناکامه کیږي یا بې پایه بیا پیل کیږي. Cloud VPN 1 پړاو تر 36,000 ثانیو، یعنې لسو ساعتونو پورې محدودوي او دا حد هغه تنظیم نه دی چې تاسو یې لوړولی شئ. بدلون باید په لرې وسیله کې وي.

Peer پوښتنه کوي، ځواب ورکوونکی پرېکړه کوي

IKE د دوو وړاندیز-ټولګو ترمنځ د سمون تمرین دی. تونل یوازې هغه ځای رامنځته کیږي چې ټولګې د ځواب ورکوونکي د منلو وړ حدودو دننه یو بل ته ننوځي، نو له حدې بهر عمر هېڅ جزوي تونل نه جوړوي. معمول تېروتنه دا ده چې د peer ترتیبات د وړاندیز پر ځای د هیلو لیست وګڼل شي. تشه پرېکړه تونل لاندې ساتي، هر څومره چې لارښوونه او ټاکنکي سم وي.

د قضیې پرانیستلو دمخه د تونل خپله حالت ولولئ، ځکه تفصیلي حالت معمولاً هغه پړاو نوموي چې ناکام شوی:

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 پړاو بل ډول چلند کوي: کله چې دواړه سرونه سره نه جوړیږي، د کیلي نوي کول لنډ وقفې ته ځي. هغه peer چې ناسمون مرګونی ګڼي تونل پرځای غورځوي، نو یو ناسمون کېدای شي د دوو بې تړاو خرابیو په څېر ښکاره شي. د کیلي نوي کولو وزن وګورئ، نه یوازې لومړنۍ اړیکه. هغه تونل چې پورته شي او بیا په منظمه ټکټکې لوېږي، ډېری د لارښوونې نیمګړتیا پر ځای د عمر ناسمون وي.

د هر څه بدلولو دمخه هغه د لوېدو وخت نښې د peer خپلو لاګونو سره ونښلوئ، ځکه د ټاکنکي یا لارې بدلون کولای شي هماغه وزن نقل کړي. که ټکټک د 2 پړاو ټایمر سره سمه وي، لامل پرته له دې چې وړاندیز ته لاس ووهل شي وموندل شو.

ټولګې د ګیټوې ډول څخه راځي

د سایفر او بشپړتیا ټولګې هغه per-tunnel پروفایل نه دي چې تاسو یې د strongSwan په څېر سمولای شئ. تاسو یې د ګیټوې ډول او IKE نسخې له مخې غوره کوئ، او د نه شتون وړ پروفایل لټول یوه ماسپښین ضایع کوي.

هغه زوړ وسیله چې د ملاتړ شوې ټولګې دننه هېڅ نه وړاندې کوي دوه رښتیني لارې پرېږدي: وسیله بدله کړئ، یا پر هغه سافټویر ګیټوې چې تاسو یې کنټرول کوئ پای ومومئ او له هغه ځایه VPC ته لارښوونه وکړئ. نور هر څه هغه حل دی چې په بل بیاکتنه کې ناکامېږي.

هرې وسیلې لپاره یوه بهرنۍ پته

د peer بهرنۍ پته باید د هغې داخلي پتې سره یو-په-یو نقشه شي. ډېر بار شوی PAT حوض نشي کار کولی, ځکه چې د یوې عامې پتې شاته څو کوربه ځواب ورکوونکي ته هېڅ لار نه ورکوي چې هغوی سره جلا کړي. چېرې چې څو کوربه باید پته شریکه کړي، تونل باید داسې ځای کې پای ومومي چې هغوی سره توپیر کړي.

هغه بهرنۍ پته هم ثابته وساتئ. وسیله د بل NAT شاته واستوئ او اړیکه پرې کیږي، که څه هم هر وړاندیز لا هم سمون لري. دا د لیکلو وړ ده چې کوم ارزښتونه د Google دي او کوم یې ستاسو: عمرونه، ټولګې او یو-په-یو NAT د هغوی په اړخ کې ثابت دي، پداسې حال کې چې وړاندیزونه، ټاکنکي، لارښوونه او د BGP لومړیتوبونه ستاسو دي.