کنسول up ښیي، strongSwan د ټینګې شوې IKE اړیکې راپور ورکوي، او پاکټونه بیا هم نه رسیږي۔ بل څه چې باید پرتله شي هغه مخکې شریک شوی کیلي نه ده، بلکې د هغو مختګونو جوړه ده چې هر لوری فکر کوي ټونل یې ساتنه کوي۔ لاندې څېړنې په ترتیب سره ترسره کړئ، ځکه لومړنۍ دوه پرېکړه کوي چې ټونل ستاسو ترافیک په ټولیز ډول لېږدولی شي که نه۔

د AWS نومونه د strongSwan اصطلاحاتو ته وژباړئ

AWS اړیکه د مراجعې خوا ته تشریح کوي: د مراجعې ګېټوې پته او ځایي CIDR ستاسو دي، او لرې CIDR د VPC دی۔ strongSwan دوه سرونه left او right بولي، ستاسو مختګ په leftsubnet کې او د VPC مختګ په rightsubnet کې وي۔ یوه جوړه چپه کول داسې ټونل جوړوي چې غلط ترافیک سره خبرې اترې کوي او هغه ټاکي۔

هغه ترتیبات ډاونلوډ کړئ چې AWS د اړیکې لپاره جوړوي او د همدې اړیکې د مرجع په توګه یې وګورئ، د ټونل پتې او مختګونه په کې شامل دي۔ که جوړولو پر مهال دواړه CIDR ساحې خالي پرېږدئ، خدمت هر لوري ته 0.0.0.0/0 تلواله کاروي۔ تنګ مختګ سره تنظیم شوی روټر بیا هېڅکله ورسره سمون نه خوري، نو یا ساحې ډکې کړئ یا ټاکونکی په قصد سره پراخ کړئ۔

دلته ناسمونکی د لارښوونې ناکامي ښکاري او نه ده۔

هغه پته ثابته کړئ چې AWS یې په رښتیا ویني

د NAT شاته روټر کولای شي IKE له هغه انټرفېس څخه ولېږي چې بل لوري هېڅکله نه دی پېژندلی۔ په AWS کې ثبت شوې ګېټوې پته باید هغه وي چې AWS په شبکه کې ویني، او روټر باید د خپل تلواله لارې پر ځای په همدې ځایي پته وټینګ شي۔

conn %default
    local_addrs = 203.0.113.10

په strongSwan کې local_addrs د IKE لپاره سرچینه پته ټاکي، او زاړه OpenSwan ترتیبات ورته نظر left بولي۔ هغه د عامې پتې لرونکي انټرفېس ته واستوئ، بیا پر NAT وسیله کې پخپله وګورئ چې UDP 500 او 4500 هغه هوسټ ته رسیږي، ځکه له پخواني روټر څخه پاتې قاعده هغه په غلې ډول غورځوي۔ سمه ټاکونکې جوړه د غلطې سرچینې پتې سره بیا هم ناکامه کیږي، او لاګ بهه پر وړاندیز اچوي۔ همدا ګمراهي لامل ده چې سرچینه پته خپله څېړنه مستحق ده۔

د لېږد قاعده تایید کړئ پر ځای چې فرض یې کړئ، ځکه هغه قاعده چې د پخواني روټر لپاره سمه وه ډېری وخت پاتې کیږي۔

پړاو 1 او پړاو 2 جلا وجګړئ

AWS د IKE او ESP غوراويې جلا لیستونه ښیي۔ هغه IKE ټولګه چې دواړه لوري مني د ESP وړاندیز په اړه هېڅ نه وایي، ځکه دواړه لیستونه خپلواک دي۔ دواړه له جوړ شوو ترتیباتو ولولئ او یو په یو یې پرتله کړئ۔

conn aws
    ike = aes256-sha1-modp1024
    esp = aes256gcm16

نحوه د پلي کولو ترمینځ نه ځي۔ هغه جوړه چې په OpenSwan کې کار کوي، لکه phase2alg=aes_gcm د ike=aes256-sha1;modp1024 سره، باید strongSwan د esp= او ike= بڼې ته وژباړل شي، او د الګوریتم نومونه توپیر لري۔ ځکه GCM د کوډ کولو پر مهال تصدیق کوي، نو جلا بشپړتیا بدلون ته اړتیا نه لري، د SHA سره جوړه شوې CBC ټولګې خلاف۔ له یوه ډیمون څخه بل ته بې ژباړې نښلول شوې د پړاو 2 کرښه داسې رد جوړوي چې د ټاکونکي ناسمونکي په څېر لوستل کیږي۔

د ټونل ښودونکی نه، د ماشوم اړیکه وګورئ

که اړیکه بار شي خو هېڅ ماشوم اړیکه پورته نه شي، یا وړاندیز یا ټاکونکي رد شوي دي۔ که ماشوم پورته شي او ټاکونکي یې ستاسو مختګونه لرې کړي، پاکټونه د ټونل رسېدو دمخه فلټر کیږي۔ د کنسول ښودونکی یوازې IKE کچه پوښي، نو نشي ویلای چې له دواړو کومه پېښه شوه۔

ipsec statusall

د ماشوم امنیت اړیکه ومومئ او په څنګ کې چاپ شوي ترافیک ټاکونکي ولولئ، بیا یې له جوړ شوو ترتیباتو مختګونو سره پرتله کړئ۔

له ځایي مختګ دننه هوسټ څخه د VPC مختګ دننه هوسټ ته ازموینه وکړئ او د بېرته راستنېدو لار او د AWS خوا هر امنیتي ډله یا شبکه ACL وګورئ۔ سم ټاکونکي پاکټ له وروسته غورځېدو نه نه ساتي۔

کله چې د ټاکونکو له سره سمون وروسته هم ناکام شي

تایید کړئ چې د دواړو خواوو لار ټونل ته ځي، بیا تایید کړئ چې NAT وسیله ترافیک هغسې نه لیکي چې تګلاره یې تمه نه لري۔ پر تګلاره ولاړ ټونل د پاکټ پتې سره سمون خوري، نو د تګلارې پرېکړې وروسته پلي شوې ژباړه پایله بدلوي۔

د بل وړاندیز له بدلولو دمخه په هر لوري یو راتلونکی او یو وتونکی پاکټ ثبت کړئ۔

په ټکټ کې ټاکونکي، د پړاو 1 او پړاو 2 وړاندیزونه او سرچینه پته ولیکئ۔ دا څلور ارزښتونه پرته له زنګ څخه ډېری site-to-site ناکامۍ تشریح کوي۔

اړوندې مقالې