د AWS څخه Azure ته سایټ VPN: لومړی د بیرته ستنیدو لاره ولیکئ
د دوو کلاوډونو ترمنځ تړل شوی ټنل تر هغه پورې هیڅ نه ثابتوي چې هر کاري سابنیټ لرې پریفکس ته ونه رسیږي. پلان په ترتیب سره بشپړ کړئ، بیا خدمت وآزمویئ.
ټنل به پورته شي. معمولاً همداسې کیږي، ځکه چې IKE یوازې د سره سمون لرونکو وړاندیزونو او د لاسرسي وړ همکار پتې ته اړتیا لري. وروسته چې ناکامه کیږي هغه د بیرته ستنیدو لاره ده: د AWS کاري بار پیکټونه ټنل ته لیږي، خو د Azure په اړخ کې هیڅوک نه پوهیږي چې 10.10.0.0/16 ته څنګه ځواب ورکړي، یا د Azure لاره په داسې جدول کې ده چې کاري سابنیټ یې نه کاروي. د هر کانسول له لمس کولو دمخه د لارو پلان ولیکئ، او ټنل به د کار ترټولو کم زړه پورې برخه شي.
ګام 1: د پتو پلان کنګل کړئ
د مشخصو ارزښتونو سره کار وکړئ. د AWS کاري بار په 10.10.0.0/16 دننه په 10.10.1.20 کې دی او په 10.20.0.0/16 دننه په 10.20.1.30 کې د Azure خدمت ته TCP 443 ته اړتیا لري. دواړه ساحې باید یو بل ته نه ورپرګنې شي، او د منلو ازموینه د خدمت جوړه ده، نه ټنل.
هغه څلور حقایق له هر څه دمخه ولیکئ، ځکه چې هر راتلونکی ګام د هغوی پر وړاندې ازمویل کیږي.
ګام 2: هغه ګیټوې ونوموئ چې د هر پای مالک دی
AWS Site-to-Site VPN کولی شي په مجازي شخصي ګیټوې یا په ټرانزیټ ګیټوې پای ومومي، او دا دواړه جلا د لارښوونې مالکان دي. Azure خپل مدیریت شوی VPN Gateway او په جلا توګه د پیرودونکو لخوا پخپله چلول شوي VM-بنسټیز وسایل وړاندې کوي. ولیکئ چې کومه جوړه لرئ، ځکه چې راتلونکی ټوپ په هر ترکیب کې توپیر لري.
د مدیریت شوي ګیټوې لپاره، هغه لاره کاپي مه کوئ چې اټکل شوې شخصي وسیله پتې ته اشاره کوي. د وسیلې لپاره، دا مه انګېرئ چې په کلاوډ کې د لارو خپریدل د میلمه عملیاتي سیسټم ترتیبوي، ځکه چې داسې نه کوي.
دلته غلطي کول داسې پلان جوړوي چې بشپړ ښکاري او پیکټونه هغې پتې ته لیږي چې هیڅکله ځواب نه ورکوي.
ګام 3: هغه لاره ولیکئ چې هر کاري بار واقعاً کاروي
لاندې هر پوله یوه جلا پلټنه ده، او په یوه کې لاره د پیکټ لپاره لاره نه ده. د ټنل له فعالیدو دمخه جدول خپلو ارزښتونو سره ډک کړئ.
| Boundary | Must reach | Owner to inspect |
|---|---|---|
| AWS workload subnet | 10.20.0.0/16 | the subnet's VPC route table |
| AWS transit gateway, if used | 10.20.0.0/16 via the VPN attachment | the table associated with that attachment |
| Azure workload subnet | 10.10.0.0/16 | effective routes on the NIC, whatever their source |
| VPN scope | both prefixes, agreed | static connection ranges or BGP advertisements |
په AWS کې، د کاري سابنیټ لارو جدول تاسو ته دی چې نوی کړئ، حتی وروسته له هغه چې BGP یا ټنل روغ شي؛ د لارښوونې کتنه دا د اړیکې برخه ګڼي. په Azure کې، د کاروونکي ټاکل شوی لارو جدول له سابنیټ سره تړل کیږي نه له مجازي شبکې سره، نو اغیزمنه لاره د VNet بلیډ کې نه، د کاري بار NIC کې وګورئ.
مدیریت شوی Azure ګیټوې کولی شي لرې پریفکس د ګیټوې خپریدو له لارې زده کړي، او UDR کولی شي هغه پریکړه باطله کړي. UDR هغه وخت ورزیات کړئ چې دلیل لرئ، نه د عادت له مخې. که ورزیات کړئ، د وسیلې پته جوړولو پرځای دې هغه راتلونکي ټوپ ته اشاره وکړي چې ګیټوې د VPN لارې لپاره خپروي. بیا د NIC پر اغیزمنو لارو بیا ولولئ، ځکه چې پریکړه واقعاً هماغه ځای کیږي.
ګام 4: پراخوالی سره سم کړئ
د BGP لپاره، هغه څه چې هر اړخ اعلانوي د بل اړخ هغه څه سره پرتله کړئ چې واقعاً زده کړي، پریفکس په پریفکس. د ثابتو لارو لپاره، ترتیب شوې لرې ساحې د ګام 3 کې لیکل شوو کاري لارو سره پرتله کړئ.
د کرپټوګرافي په اړه سره سمون لرونکې IKE اړیکه دا ثبوت نه دی چې کوم اړخ 10.10.0.0/16 یا 10.20.0.0/16 زده کړی. دوه ټنلونه کولی شي پورته وي پداسې حال کې چې یو اړخ ستاسو د پلان شوي /16 پرځای یوازې یو /24 اعلانوي. پریفکس په لارښوونې جدول کې وګورئ، د ټنل په حالت کې نه. ناسمونې وروسته د یو کار کوونکي او یو هغه سابنیټ په توګه ښکاري چې هیڅکله ځواب نه ورکوي.
ګام 5: خدمت له ریښتیني سرچینې وآزمویئ
د AWS امنیتي ګروپونو او شبکې ACL، د Azure NSG او په لاره کې د هر وسیلې فلټر کې د پلان شوي بهیر اجازه ورکړئ. بیا له 10.10.1.20 څخه د تصویب شوې خدمت پتې او پورټ ته یوه اړیکه پرانیزئ او تایید کړئ چې ځواب هماغه سرچینې ته بیرته راځي.
د کلاوډ امنیتي ګروپونه او NSG دواړه stateful دي، نو رد شوی بیرته راستنیدونکی پیکټ د لارښوونې نښه ده، نه هغه قاعده چې په مخالف لوري یې لیکل هیر کړي دي.
له هر ګیټوې څخه ping هیڅ شی نه فیصله کوي. ګیټوې پتې ته ICMP د کنټرول پلین لاره تمرینوي، نه هغه لیږدول شوې TCP خدمت چې کاري بار ته اړتیا لري.
بیرته اخیستل او ثبت
د لارو مالکان د ټنل پیژندونکو ترڅنګ ثبت کړئ او د بدلون دمخه لارو جدولونه وساتئ. که بدلون باید وویستل شي، د ټنل له ماتی دمخه کاري لارې لرې کړئ، ترڅو هیڅ سابنیټ هغه راتلونکي ټوپ ته نه کتنه وکړي چې نور نشته.
بیا وروسته د سابنیټ لېږد یا spoke نښلونې د نوي کولو لپاره یوه ټاکلې ځای لري، د هغه فعال ټنل پرځای چې د هغې لارې تور پورې کوي چې هیڅکله یې مالکیت نه درلود.