په Cisco ASA کې tunneled ډیفالټ لاره: کله په رښتیا پلي کیږي

د لیرې لاسرسي کاروونکی د ASA هاخوا هیڅ شي ته نه رسیږي، پداسې حال کې چې هماغه سرور د داخلي LAN څخه د ping ځواب ورکوي. ټنل پورته کیږي، کلاینټ د pool څخه پته اخلي، او پیکیټ بیا هم د انټرنیټ ډیفالټ له لارې وځي یا ورک شي. دا بڼه معمولاً معنا لري چې ډيکریپټ شوي ترافیک خپله لاره ونه مونده او عادي ډیفالټ ته ولویده. سمون بله NAT قاعده نه ده؛ سمون tunneled ډیفالټ لاره ده.

له کانفیګ نه نه، له نښې پیل کړه

وګوره چې پیکیټ چېرته ځي، نه چې ته یې چېرته تلل تمه درلوده. د ناکامې ناستې پر مهال د باندې انټرفیس کې اخیستل شوی کیپچر ښیي چې ډيکریپټ شوی پیکیټ د ISP ګیټوې په لور روان دی او د pool پته لا سالمه ده، یا هیڅ نه ښیي ځکه پلټنه ناکامه شوه. په دواړو حالاتو کې ټنل ستونزه نه ده.

show vpn-sessiondb کې ټنل روغ ښکاري، او همدا لامل دی چې خلک IKE ډیبګ ته دوام ورکوي.

له ACL غورځېدو څخه یې جلا کوونکې شی لوري ته کتنه ده. ACL غورځېدنه لاګ کیږي او شمیرل کیږي، خو نه شته لاره د برابرې ننوتنې پرته د پلټنې ناکامي جوړوي. د کلاینټ د منزل لپاره show route چلوه او ولوله چې ASA په رښتیا څه وټاکل، په دې کې چې ډیفالټ وټاکل شو که نه او کوم یو.

tunneled پلټنه څنګه توپیر لري

د Cisco د ASA 9.23 سټاټیک-روټینګ لارښود کې د ډيکریپټ شوي VPN ترافیک لپاره جلا ډیفالټ مستند شوی، چې سټاټیک یا زده شوې لاره نه لري. tunneled کیلما هغه لاره نښه کوي، نو ډيکریپټ شوی پیکیټ کولای شي هغه بل اړخ ته ولوېږي چې ASA خپل ټرانسپورټ لپاره کاروي، هغه ته نه. نورې ځانګړې لارې بیا هم ګټي، همدا لامل دی چې کلاینټ کولای شي د داخلي ګیټوې له لارې 10.0.0.0/8 ته ورسیږي او نور هر څه له لاسه ورکړي.

لږترلږه ترتیب دوه ډیفالټ لارې ساتي چې بېل بېل راتلونکي اړخونه لري. یوه د ASA خپل ترافیک وړي، بله هغه ډيکریپټ شوی ترافیک وړي چې ښه لاره نه لري. دواړه راتلونکي اړخونه باید له هغه انټرفیس څخه د لاسرسي وړ وي چې ته یې ورسره نښلوې.

route outside 0.0.0.0 0.0.0.0 198.51.100.1
route outside 0.0.0.0 0.0.0.0 10.20.30.1 tunneled

که دواړه ډیفالټ یو شان راتلونکي اړخ ته اشاره وکړي، کیلما هیڅ نه بدلوي او نښه به ونه ځي.

هغه محدودیتونه چې تیا کوي چې کار کوي که نه

هماغه لارښود یوازې یو tunneled ډیفالټ ته اجازه ورکوي او وایي چې د دې لپاره ECMP نه ملاتړ کیږي، نو په هغه لار کې بار نه شې ویشلای. دا د لارې تعقیب، د بېرته لارې تصدیق او ځینې انسپیکشن او مدیریت جریان اړوند محدودیتونه هم لیستوي. د فیچر شاوخوا د ډیزاین کولو دمخه یې د خپل نصب شوي خپرونه سره پرتله ولوله. هغه ډیزاین چې دا نادیده ګیري معمولاً هر چېرته نه، بلکې یو ځانګړي ځای کې ناکام کیږي، همدا لامل دی چې نښه دوره دوره ښکاري.

په غیر متقارن ډیزاینونو کې د بېرته لارې تصدیق ډېر چیچل کوي. که ځواب د هغه انټرفیس څخه توپیر ولري چې ASA تمه لري، پیکیټ د روټینګ اهمیت له ترلاسه کولو دمخه غورځول کیږي. تصدیق بند کړې چې راتلونکی اړخ مجبور کړې، د هغې پرځای ټوپولوژي یا بېرته لار سمه کړه.

د لارې تعقیب جلا جال دی: تعقیب شوی شی معمولاً عادي ډیفالټ ساتي، tunneled نه.

کیلما څه نه کوي

دا هغه سرچینه پته نه ټاکي چې ASA د IKE جوړولو لپاره کاروي. د ټنل باندې پای پلیټفارم خپل انټرفیس او سرچینه ټاکل تعقیبوي، او tunneled ډیفالټ په هغه پریکړه کې هیڅ برخه نه لري. د هغې بدلول هغه phase 1 نه جوړوي چې له غلطې پتې پیل کیږي.

دا راتلونکی اړخ پراکسي هم نه جوړوي. که منزل HTTP CONNECT تبادله تمه لري، پراکسي هوسټ ته خام IP پیکیټونه لېږل تاته یوازې هغه هوسټ درکوي چې هغه نه روټ کوي. پرځای یې د کلاینټ ملاتړ شوی پراکسي میکانیزم کانفیګ کړه.

او دا لاندې ته فوروارډینګ نه جوړوي. هغه ګیټوې چې ته ورته اشاره کوې بیا هم VPN pool ته د بېرته لارې اړتیا لري، او همدارنګه چېرته چې ډیزاین غواړي د سرچینې ژباړه.

لاره له سره تر پایه تصدیق کړه

کله چې لاره ځای پر ځای شوه، څلور شیان په ترتیب سره وګوره: د pool اړتیا وړ منزل لپاره show route، نوي راتلونکي اړخ په لور انټرفیس کې کیپچر، په خپله ګیټوې کیپچر، او له هغه ګیټوې څخه د pool پتې ته بېرته لار. لومړي دوه ثابتوي چې ASA هغه لاره وټاکله، او وروستي دوه ثابتوي چې هلته څوک ځواب ورکوي.

که ګیټوې ځواب ورکوي خو کلاینټ هېڅکله ځواب نه ویني، د روټینګ جدول بیا لمسولو دمخه د سرچینې ژباړه او بېرته لار وګوره.

هغه خپرونه ثبت کړه چې پرې تصدیق کړې، ځکه د محدودیتونو لیست د نسخې پورې تړلی دی او هغه ډیزاین چې په یوه ټرین کار کوي ممکن په بل کې بله لاره غواړي. هغه یادښت د کانفیګ ټوټې څخه اوږد ژوند کوي.