د ASA DHCP ریلې د سایټ-تر-سایټ VPN له لارې: ګام په ګام لارښود

ریله په دریو پړاوونو کار کوي او یوازې منځنی پړاو VPN تېروي. کلیانت په څانګه کې براډکاسټ کوي، ASA هغه براډکاسټ په DHCP سرور ته یونیکاسټ غوښتنه بدلوي، او سرور د کلیانت پرځای د ریلې پتې ته ځواب وایي. پړاوونه په همدې ترتیب وپلټئ، او د «ریله خرابه ده» ډېری پېښې په نیمګړې پالیسي یا ناسم لوستل شوي setroute کرښه کې پای ته رسېږي.

لومړی پړاو: په کلیانت ته مخامخ انټرفیس کې ریله فعاله کړئ

د څانګې په ASA کې ریله د هغه انټرفیس ځانګړنه ده چې کلیانتونو ته ګوري. سرور کولای شي په نړیواله توګه د خپل رسېدونکي انټرفیس سره اعلان شي، یا د همدې کلیانت ته مخامخ انټرفیس لاندې، ترڅو د لارښوونې جدول وتل وټاکي. دا دوه بڼې د یوبل بدلېدونکې نه دي، او غلطې بڼې کاپي کول لومړنی ځای دی چې لارښود له سمې لارې اوړي.

له هر بدلون دمخه روانه ترتیبات وګورئ: کوم انټرفیس ریله فعاله لري، کومه سرور بڼه شته، او ایا setroute د کلیانت انټرفیس سره نښلول شوی. که ASA د بلې برخې لپاره هم DHCP سرور چلوي، ودروئ او د محدودیتونو لیست ولولئ؛ سرور او ریله په یو ډیوایس کې یوځای نشي فعالېدای.

ریله خپله کلیانت ته مخامخ پته د ګېټوې پتې په برخه کې اېږدي. سرور به همدې پتې ته ځواب ووایي، نو باید له لرې سایټ څخه د ټونل له لارې وررسېدونکې وي، نه یوازې په سیمه ییز ډول.

دویم پړاو: د ASA جوړ شوی ټرافیک د ټونل له لارې وړئ

دا هغه ګام دی چې خلک یې پرېږدي. د پالیسي پر بنسټ سایټ-تر-سایټ VPN معمولاً د سبنیټونو ترمنځ ټرافیک لپاره جوړېږي، او د ریلې غوښتنه پخپله ASA جوړوي. که د ټونل د لاسرسي لیست او کریپټو نقشه یوازې له څانګې هوسټ څخه سرور سبنیټ ته د بهیرونو سره سمون ولري، کېدای شي د ریلې پاکټ هېڅکله ټونل ته ونه ننوځي. د لاسرسي لیست په دواړو لورو وګورئ، نه یوازې له څانګې سرور ته کرښه.

ډاډ ترلاسه کړئ چې د پام وړ ټرافیک د ASA د ریلې سرچینه او د سرور پته پوښي، او د بېرته راتګ لوری هم اجازه لري. په VTI ولاړ ډیزاین کې د لارښوونې پرېکړه ساده ده، خو په VTI باندې د ریلې ملاتړ په یو ځانګړي خپراوي کې راغی؛ د ASA د DHCP لارښود 9.14(1) په ګوته کوي، نو له زوړ وسیله ته د VTI بېلګې کاپي کولو دمخه عکس وګورئ.

له ASA څخه سرور ته ping پخپله ډېر څه نه ثابتوي. کېدای شي له بلې لارې، له بلې سرچینې پتې سره، یا د هغې پالیسۍ لاندې بریالی شي چې د ریلې پاکټونه ورسره سمون نه لري.

درېیم پړاو: ځواب او د setroute اختیار ولولئ

RFC 2131 وایي چې کله هغه برخه صفر نه وي، سرور خپل ځواب giaddr کې د پتې ته لېږي. نو د بېرته راتګ لاره باید ریلې پتې ته وګرځي, او د ټونل پالیسي باید له سرور څخه ریلې ته لوری اجازه کړي. که غوښتنه تېره شوه خو وړاندیز هېڅکله ونه رسېد، دلته کتل پکار دي.

بیا دوه سره ورته اورېدونکي شيان بېل کړئ. د setroute کليمویی هغه ډیفالټ-روټر اختیار بدلوي یا زیاتوي چې ASA کلیانت ته ورکوي. دا په ASA باندې لاره نه نصبوي او VPN پالیسي نه جوړوي. هغه کلیانت چې پته ترلاسه کوي خو چېرته نه رسېږي، ډېری وخت د setroute یا سکوپ ستونزه لري، نه د ټونل. دا په هغه کلیانت سره وازموئ چې سټاتیک ګېټوې نلري او وګورئ په وړاندیز کې کوم ډیفالټ روټر ښکاري.

وړاندیز له سره تر پایه ولولئ: وړاندې شوې پته، ماسک، ډیفالټ روټر، DNS او د کرايې وخت. بیا پرېږدئ چې کرایه نوي شي. هغه ریله چې یو ځل کار کوي او د نوي کولو پر مهال ناکامېږي، معمولاً د سکوپ، کرايې یا د بېرته راتګ لارې ستونزه لري چې لومړنۍ تبادله یې پټه کړې وه.

له دې دمخه چې ووایم سمه شوه، څه ګورم

له کلیانت پیل کړئ او براډکاسټ ونیسئ، بیا ډاډ ترلاسه کړئ چې ASA هغه په خپله پته د giaddr په توګه ریلې کړ. په لرې اړخ کې ډاډ ترلاسه کړئ چې سرور هغه غوښتنه لیدلې او د څانګې سره سم سکوپ ټاکلی. بیرته څانګې ته راغلو، ډاډ ترلاسه کړئ چې کلیانت وړاندیز منلی او خپل ګېټوې ته رسېږي.

که کوم پړاو غلی وي، پرځای د دې چې بله ریلې اعلامیه زیاته کړئ، اړوند پالیسي یا لاره وګورئ. د ریلې ترتیبات معمولاً هغه وخت چې څوک يې لوړوي سم وي؛ هغه څه چې بدل شوي د ټونل پالیسي یا د بېرته راتګ لاره ده.

درې پړاوونه په بدلونونو ثبت کې ولیکئ: کلیانت ته مخامخ انټرفیس، هغه VPN پالیسي چې ریلې ټرافیک پوښي، او د سرور بېرته راتګ لاره giaddr ته. همدا ثبت بل څانګې جوړول له ډیبګنګ ناستې پرته تکرارېدونکې کړنه جوړوي. دا بل انجینر ته هم وایي چې لومړی کوم کمانډ محصول راټول کړي.