په AWS Client VPN کې DNS: د VPC resolver وکاروئ، نه subnet

endpoint په 10.0.8.0/24 کې دی، نو resolver باید 10.0.8.2 وي. دا هغه استدلال دی چې تر ټولو ډېر یې اورم او دوه ځله غلط دی. Route 53 Resolver په لومړني VPC IPv4 حد جمع دوه ځواب ورکوي، چې د 10.0.0.0/16 VPC لپاره 10.0.0.2 دی، که endpoint کوم subnet وکاروي. دوهمه تېروتنه ډېره غلې ده: په endpoint کې سمه پته ایښودل دا نه مانا لري چې د client عملیاتي سیستم به یې کله هم څه وپوښتي. دواړه تېروتنې یو شان نښه ورکوي: د نومونو حل په ځینو clientونو کې کار کوي او په نورو کې ناکامېږي.

افسانه د subnet له تړاو پیلېږي

تړاو د دې په اړه دی چې د client اړیکو لپاره elastic network interfaces چېرې دي، نه د دې چې کومه resolver پته شته. د endpoint subnetونه clientونو ته په VPC دننه پته ورکوي، او هر یو یې خپل resolver نه لري.

کله چې دا دوه نظرونه بېل کړئ، حساب نه پټېږي او د ستونزې حل client ته ځي، چېرې چې د دې پېښو ډېری واقعاً پای ته رسېږي.

له لومړني VPC حد څخه پته محاسبه کړئ

د VPC لومړنی IPv4 CIDR واخلئ او د شبکې پتې ته دوه ورزیات کړئ. 10.0.0.0/16 10.0.0.2 ورکوي، 172.31.0.0/16 172.31.0.2 ورکوي، او دوهم حد لرونکی VPC resolver په لومړني کې ساتي. په هغه VPC کې دننه 10.0.8.0/24 subnet یې نه خوځوي. پته د VPC ID ترڅنګ ولیکئ، مخکې له دې چې endpoint ته لاس ووهئ، ځکه دا شمېره د VPC ځانګړنه ده، نه د اړیکې.

VPC په link-local پته 169.254.169.253 هم ځواب ورکوي. دا پته له VPC دننه رسېدونکې ده، خو د تونل بل سر ته د یو لپ ټاپ لپاره عمومي مسیر شوې منزل نه ده.

نو دوه سمې resolver پتې شته، او هېڅ یوه یې subnet جمع دوه نه ده.

د endpoint تنظیم څه کوي او څه نه کوي

Client VPN endpoint د DNS سرور ډکټونه لري، او چېرې چې console د VPC resolver اختیار وړاندې کوي هماغه نظر ډکوي. د هغو تنظیمول بدلوي چې خدمت د اړیکې د جوړېدو پر مهال clientونو ته څه ورکوي. دا نه بدلوي چې یو ناسم مدیریت شوی OpenVPN client له هغه ارزښت سره څه کوي، ځکه client باید هغه په عملیاتي سیستم کې پلي کړي. «زما په Mac کې کار کوي خو په Linux بکس کې نه» له همدې تشې راځي.

په Linux کې د resolver یوځایوالی د اړیکو مدیر ملکیت دی، نه د کاروونکي. /etc/resolv.conf په لاس سمول ثابتوي چې پته د یوې ناستې لپاره کار کوي او بیا په بیا تړلو کې ورکېږي — ځکه ډېرې سمې شوې پېښې بله سهار بېرته راځي.

له تړلو وروسته په client کې فعال resolver وګورئ، نه د endpoint د تنظیم پاڼه.

split tunneling کولای شي سم resolver مات کړي

په split tunneling کې یوازې هغه لارې کارول کېږي چې تونل ته ورټېل وهل شوې وي. که د resolver پته په هېڅ لار نه وي پوښل شوې، پوښتنه له سیمه ییز انټرفېس څخه وځي او ستاسو کورنی روټر ځواب ورکوي. په endpoint کې پته لا هم سمه ده او لټون لا هم ناکامېږي. د resolver لپاره لاره ورزیاته کړئ، بیا بیا ازموینه وکړئ.

یو بل پسې پوښل شوې سیمه ییزې حدونه هماغه پایله په لا بد بڼه ورکوي: پوښتنې ته ځواب رارسي، یوازې له غلط سرور څخه.

د Amazon DNS پتې لپاره security groups مه خلاصوئ

کله چې لټونونه وخت تېر شي، طبعي غبرګون دا وي چې هغه قاعده ورزیاته کړو چې د resolver پتې ته UDP 53 اجازه ورکوي. AWS مستند کوي چې security groups او شبکه یي ACL د Amazon DNS ترافیک هغسې نه فلټروي لکه څنګه چې خپل DNS انسټانس ته ترافیک فلټروي. هغه قواعد خلاصول د VPC resolver لپاره هېڅ نه بدلوي او پرته له سببه پوله پراخوي. هغه resolver چې تاسو پخپله چلوئ بېله پېښه ده او واقعاً خپل قواعد غواړي.

که ستاسو په ډیزاین کې دواړه وي، مخکې له دې چې هره قاعده سمه کړئ، وګورئ چې client واقعاً کوم ته اشاره کوي.

لاره وګورئ، بیا بل څه اندازه کړئ

یو عام نوم حل کړئ، په VPC پورې تړلي خصوصي هوسټ شوي زون کې ثبت شوی خصوصي نوم حل کړئ، او د دواړو ترمنځ د client فعال resolver ولولئ. دا ترتیب «د resolver پته غلطه ده» له «زون نه دی تړل شوی» او «client تنظیم نادیده کړ» څخه بېلوي. هر یو بېل سمون لري، او هېڅ یو د throughput ستونزه نه ده.

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