شخصي DNS په VPC کې کار کوي خو د VPN له لارې نه
شخصي نوم چې د EC2 په داخل کې حل کیږي خو د VPN له لارې نه، د resolver د لارې ستونزه ده. د زون د ریکارډ له بدلولو مخکې د ناکامۍ بڼه ولولئ.
یو شخصي نوم د EC2 له انسټنس څخه حل کیږي خو د VPN له لارې تړل شوي لپ ټاپ څخه نه، او زون په کنسول کې سم ښکاري۔ لومړنی هڅه د ریکارډ سمول دي، چې تقریباً هیڅکله ستونزه نه وي۔ ریکارډ یو چا ته ځواب وایي؛ یوازې ستاسو لپ ټاپ ته ځواب نه وایي۔ د دوو غوښتونکو ترمنځ توپیر دا دی چې کوم resolver پوښتي او آیا دغه resolver د VPC د DNS لید ته ملاتړ شوې لاره لري۔
زه د دې په ثابتولو پیل کوم چې ریکارډ شته، بیا پاتې وخت د پوښتنې په لاره تیروم۔ دا جلا سیستمونه دي او په بیلابیلو بڼو ناکام کیږي۔
د هر څه له بدلولو مخکې د ناکامۍ بڼه ولولئ
درې پایلې درې بیلابیل شیان معنا لري، او یوه پوښتنه دوی جلا کوي: د هغه resolver په وړاندې چې کلاینټ واقعاً کاروي د نوم لپاره dig چل کړئ۔
| What you see | What it usually means | First thing to check |
|---|---|---|
| SERVFAIL, or a timeout after several seconds | No path to the resolver, or the resolver cannot reach AWS | Route to the endpoint and the security policy on port 53 |
| NXDOMAIN from a resolver that did answer | The resolver replied, but the zone is not in its view | Zone association or the forwarding rule for that namespace |
| A public address for an internal name | Split DNS is not in effect for this client | Which resolver the client is configured to use |
د وخت ختمیدل د شبکې په اړه یوه څرګندونه ده۔ NXDOMAIN د DNS لید په اړه څرګندونه ده۔ عامه ځواب د پالیسۍ په اړه څرګندونه ده۔ د وخت د ختمیدو پر مهال د زون ریکارډ سمول په قضیه کې یوازینی ګټور ثبوت غورځوي۔
ولې په VPC کې د جمع دووه پته لرې resolver نه ده
CIDR جمع دووه پته د VPC دننه د سرچینو لپاره محلي خدمت دی۔ AWS مستند کوي چې له محلي شبکو، یا د بل VPC د DNS سرورونو څخه پوښتنې مستقیمې هغې پتې ته لیږل ملاتړ شوي نه دي او کیدای شي بې ثباته پایلې ورکړي۔
دا دا معنا نه لري چې تجربه هیڅکله کار کوونکې ښکاري نه۔ دا معنا لري چې چلند هغه تړون نه دی چې په مرستې سکریپټ کې یې کیښودلای شئ۔ ملاتړ شوی لوری یو راغونډ Resolver endpoint دی: ستاسو د VPC په داخل کې د پتو یوه جوړه، چې ستاسو تر کنټرول لاندې شبکې څخه د لاسرسي وړ وي او له AWS څخه بهر راغلې پوښتنې قبولوي۔
لاره په هغه ترتیب جوړه کړئ چې پکې پاکه ناکامه کیږي
باید درې ټوپونه وي او هر یو خپله د ناکامۍ لاره لري۔
VPN client -> approved DNS forwarder
forwarder -> forwarding rule for internal.example
forwarding rule -> Resolver inbound endpoint addressesلیږدونکي ته د VPN له لارې د endpoint پتو ته مسیر ته اړتیا ده، او د بېرته راتلو لاره هم باید کار وکړي۔ د پورټ 53 په عادي DNS لپاره endpoint د UDP او TCP له لارې ځواب وایي، نو دواړه پروتوکولونه باید اجازه ولري او دواړه باید په منځ کې هر ډول حالتیز تفتیش ته دوام ورکړي۔
بیا د DNS لید جلا وګورئ۔ شخصي کوربه شوی زون یوازې هغو VPCs ته ښکاري چې ورسره تړلی وي، یا د یوې ارادي شریکولو تړون له لارې۔ د لاسرسي وړ endpoint پخپله هر شخصي زون په خپل حل کونټیسټ کې د حل وړ نه کوي۔
وتونکی endpoint مخالف لوري ته خدمت کوي او ستاسو د لپ ټاپ څخه راغلې پوښتنې ته ځواب نه وایي۔
له دواړو سرونو څخه تایید کړئ
له کلاینټ څخه لیږدونکي ته، بیا له لیږدونکي څخه endpoint ته پوښتنه وکړئ۔ که کلاینټ ناکام شي او لیږدونکی بریالی شي، نو تشه د هغو دواړو ترمنځ ده۔
که دواړه ناکام شي، د endpoint امنیتي پالیسي او هغې سرچینې پتې ته وګورئ چې هغه واقعاً یې ویني۔ د NAT شاته لیږدونکی د لپ ټاپ د VPN پتې پرځای د NAT پته وړاندې کوي، او یوازې همدا توپیر د پوښتنې غورځولو لپاره کافي دی۔ که دواړه بریالي شي خو اپلیکیشن لا هم ناکام شي، ممکن اپلیکیشن له هغه resolver پرته بل وکاروي چې تاسو یې ازموینه کړې۔
عامه او شخصي نوم ځایونه په اراده جلا وساتئ۔ Split DNS هغه پالیسي ده چې تاسو یې تنظیموئ، نه د یوې پلټنې ناڅاپي ډیټا بیرته راګرځولو اړخیزه اغیزه۔
هغه څه چې زه به یې نه کوم
زه به داسې NAT قاعده اضافه نه کړم چې یوه پلټنه یې چلوله او هغه ته به ډیزاین ووایم۔
زه به هر لرې کلاینټ جمع دووه پتې ته نه اوړم یوازې ځکه چې یوې ازموینې یو ځل ریکارډ بیرته راوګرځاوه۔ او زه به د endpoint امنیتي پالیسي ټول VPN حوض ته نه پراخوم کله چې یوازې یو لیږدونکي ته لاسرسی ورته وي۔ که سازمان لا دمخه په VPC داخل کې تصویب شوی لیږدونکی چلوي، لومړی هغه ډیزاین ولولئ، ځکه چې تاسو چې دوهم endpoint ورزیاتوئ هغه دی چې هیڅوک یې مستند نه کوي۔