د AWS Client VPN د کاروونکي CIDR د VPC له ساحې سره نشي یو ځای کیدلی

د AWS Client VPN پای ټکی د کاروونکو پتې له هغه حوض څخه ویشي چې تاسو یې غوره کوئ، او AWS د پای ټکي له جوړولو دمخه هغه حوض د هدف شبکې سره څیړي. څیړنه دا نه ده چې سابنیټ خالي ښکاري که نه. دا ده چې حوض د VPC له ساحې سره یو ځای کیږي که نه، او ځواب یو شان دی که نن یو EC2 انسټانس هغه پتې کاروي یا نه. یو ځای کیدل د ساحو پوښتنه ده، د ویش پوښتنه نه.

پنځه څیړنې په ترتیب سره وکړئ. په لومړۍ ناکامه څیړنه ودریږئ، ځکه چې هیڅ وروستی ګام نشي کولی پخوانی پرېکړه سمه کړي.

یو ځای کیدل د ساحو ازموینه ده، د خالي پتو ازموینه نه

له VPC CIDR څخه پیل وکړئ، نه له هغه سابنیټ چې غواړئ یې ونښلوئ. د 172.20.0.0/22 حوض د 172.20.0.0/16 VPC دننه دی او رد کیږي حتی کله چې هیڅ سابنیټ یې نه نیسي، ځکه چې یو ځای کیدل د ساحو ځانګړنه ده، د اوسنیو ویشونو نه. بیا هغه منزلونه ورزیات کړئ چې پای ټکی ورته لارښوونه کوي: پییر VPC، ټرانزیټ ګیټوې او د سایټ-تر-سایټ نښلون له لارې سیمه ایزې ساحې. هره ساحه چې کاروونکي ته یې د رسیدو اړتیا وي په لیست کې ده.

هغوی له حساب څخه راټول کړئ، نه له حافظې: aws ec2 describe-vpcs --query "Vpcs[].CidrBlock"، د هغه سابنیټ د لارښوونې جدول داخلې سره یو ځای چې غواړئ یې ونښلوئ.

د حوض اندازه د جوړولو دمخه ټاکل کیږي

AWS په Client VPN کې د /22 او /12 ترمنځ IPv4 کاروونکي حوض مني. /24 ډیر کوچنی دی، /8 د مستندې ساحې بهر دی، او دواړه تېروتنې د حوض د کاري بار سابنیټ په څیر اندازه کولو څخه راځي. د تمه شوو یوځای کاروونکو او حاشیې له مخې یې اندازه کړئ، بیا د اجازه ورکړل شوې مختاړې ته یې راټول کړئ.

مخکې له دې چې یې کنسول ته ولیکئ، حساب وګورئ، ځکه چې غلطه ټایپ شوې مختاړه پرته له هېڅ خبرداري د حوض اندازه بدلوي:

python3 -c "import ipaddress; p=ipaddress.ip_network('172.16.0.0/22'); print(p.num_addresses, p.prefixlen, p.overlaps(ipaddress.ip_network('172.20.0.0/16')))"

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

ریزولوور خپله د پت نقش لري

د VPC ریزولوور د VPC ساحې بنسټیز پت ته دوه ورزیات کړي ځواب ورکوي، کوم چې اړینه نه ده چې ستاسو د نښلول شوي سابنیټ دننه وي. دا انګیرنه چې ریزولوور باید د کاروونکي حوض کې اوسي، یا د هغه پت شاوخوا سابنیټ جوړول، پرته له دې چې څه بدل کړي توکي زیاتوي. مهمه دا ده چې پای ټکی داسې DNS تنظیم ولري چې کاروونکی یې پلي کولی شي او ریزولوور له تونل څخه د لاسرسي وړ وي.

ریزولوور، د کاروونکي حوض او نښلول شوی سابنیټ په پت پلان کې د دریو جلا توکو په توګه ولیکئ. هغوی په خپلواکه توګه ناکام کیږي، او د یوې سمېدو په اړه بل دوو ته هیڅ نه وایي.

څلور ساحې چې د جوړولو پر مهال یې ژمن یاست

د کاروونکي IPv4 CIDR د جوړولو پر مهال ثابت دی. د DNS سرور بدلول، نښلون زیاتول، د امنیتي ګروپ بدلول، د اجازې قواعد سمول یا د split-tunnel لارو بدلول ټول عادي سمونونه دي، او هیڅ یو یې د حوض نوم نه بدلوي. همدا نابرابري لامل کیږي چې دا د بیاکتنې وړ وي: ارزانه تنظیمات هغه دي چې وروسته یې بدلول غواړئ، او ګران هغه دی چې لومړی یې ژمن یاست. د بدلون کړکۍ له پلان کولو دمخه د پای ټکي تفصیل ولولئ.

مخکې له دې چې بیا جوړول انګیرئ، ځای پرځای شوی پای ټکی وڅیړئ. aws ec2 describe-client-vpn-endpoints حوض، DNS، د split-tunnel بیرغ او نښلونونه په یوه ځواب کې بیرته راولي، چې معمولا د بیا جوړولو د ردولو لپاره کافي دی.

د پای ټکی بدل کړئ، د پیوند کولو پر ځای

نوی پای ټکی نوی پای ټکی دی، نه کډوالی. شته غونډې ورته نه ځي، د کاروونکو پروفایل بل نوم ته اشاره کوي، او هره هغه تنظیم چې تاسو یې طبیعي ګڼلې وه باید بیا جوړ شي: د سرور سند، تصدیق، نښلونونه، لارې، د اجازې ګروپونه، ثبت. د اړینې خصوصي خدمت او د هغه منزل پر وړاندې چې باید رد شي، د یو کاروونکي سره اعتبار وکړئ، بیا لاسرسی پراخ کړئ. هر څه چې پرېږدئ وروسته د ملاتړ ټکټ کیږي.

زوړ پای ټکی تر هغه پورې چالان وساتئ چې دا تصدیق تیر شي، او یو اداري لار وساتئ چې نوې ته اړه نه لري.

یوه پوله چې د یادولو وړ ده: دا د IPv4 کاروونکي حوض پوښي. په Client VPN کې د dual-stack او IPv6 ترافیک تنظیمات خپل پت اچونې ماډل تعقیبوي، نو دا لیست پرته له دې چې د هغه حالت اسناد ولولئ کاپي مه کړئ.