له سایټ VPN له لارې لرې ASA ته SSH: ګام په ګام

تاسو یو SSH کلاینټ د لرې ASA داخلي پتې ته نیسي او د نښلولو پر مهال سیشن مري۔ فایر وال د خپل سایټ څخه ځواب ورکوي، تونل ښکاري، او بیا هم په 22 پورټ کې هیڅ نه اوري۔ په ډیرو دې پېښو کې پاکټ هیڅکله د مدیریت منلو ته نه رسیږي، ځکه چې ازمویل شوې لار هیڅکله د مدیریت لارې په توګه نه وه ډیزاین شوې۔ لاندې بهیر په ترتیب سره تعقیب کړئ او نیمګړتیا به د ځای بدلولو مخه ونیسي۔

هغه پته وټاکئ چې تاسو یې واقعاً اداره کوئ

درې ډیزاینونه ورته ښکاري او مختلف چلند کوي: ASA عامه VPN ته مخامخ پتې ته رسیدل، د IPsec له لارې داخلي انټرفېس ته رسیدل، او ځانګړي مدیریت انټرفېس ته رسیدل۔ د هرې اجازې له لمس کولو دمخه د اداره کوونکي سرچینې پته، دقیقه مقصد پته او TCP 22 ولیکئ۔ هر څه چې وروسته دي په همدې جوړه پورې تړلي دي۔

هغه تونل چې دوه سرور VLANونه وړي ممکن د فایر وال انټرفېس پته یا د اداره کوونکي مدیریت سبنیټ هېڅ ونه وړي۔ د سایټ-تر-سایټ پالیسۍ لپاره د جالب ټرافیک لیست وګورئ او تایید کړئ چې د ASA خپله پته د مقصد په توګه ښکاري، نه یوازې هغه سبنیټونه چې د هغه له لارې تیریږي۔

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

management-access د انټرفېس ځانګړی دی

د management-access امر ASA ته وایي چې د VPN له لارې راتلونکي مدیریت اړیکې په نومول شوي انټرفېس کې ومني۔ دا مسیر نه جوړوي، SSH اجازه نه زیاتوي، او په یو وخت کې په هر انټرفېس نه پلي کیږي۔ که د مقصد انټرفېس نومول شوی نه وي، اړیکه د تصدیق دمخه غورځول کیږي۔

دلته دوه استثناوې چیچي۔ یوازې د مدیریت لپاره انټرفېسونه د دې میکانیزم څخه بهر دي، او د ASA 9.20 مدیریت لارښود یادونه کوي چې ډیفالټ CiscoSSH سټک د VPN له لارې د انټرفېسونو ترمنځ SSH نه ملاتړ کوي، پداسې حال کې چې ASA SSH سټک یې ملاتړ کوي۔ د مسیرونو لپاره د وخت تیرولو دمخه په ځای شوي نسخه کې فعال سټک تایید کړئ۔

د ننوتلو غوښتنې دمخه څلور دروازې

د کلاینټ او د کارن نوم غوښتنې ترمنځ څلور خپلواکې دروازې ولاړې دي: د مدیریت جوړې لپاره د مسیر او تونل سمون، هغه انټرفېس ACL چې ASA پتې ته TCP 22 اجازه ورکوي، هغه ssh اجازه چې د اداره کوونکي سرچینه پوښي، او د هغه کارن لپاره AAA تصدیق۔ هر یو یې کولی شي پاکټ غورځ کړي پرته له دې چې کلاینټ ته ووایي کومه دروازه وتړل شوه۔

د هر څه بدلولو دمخه وګورئ چې کومه دروازه ناکامه کیږي، د packet-tracer په کارولو سره: packet-tracer input inside tcp 10.10.5.20 50000 10.20.1.1 22 detailed۔ تعقیب ACL، د NAT پړاو او to-the-box پرېکړه نوموي، چې معمولاً د مسیر ستونزې له منلو ستونزې څخه جلا کولو لپاره کافي دي۔

تنگه اجازه ولیکئ، پراخه نه

اجازه د تصویب شوې اداري سبنیټ او هغه انټرفېس پورې محدوده کړئ چې د تونل ټرافیک ترلاسه کوي: ssh 10.10.5.0 255.255.255.0 inside۔ دا د aaa authentication ssh console LOCAL په څیر د تصدیق میتود او نومول شوي ځایي حساب سره یوځای کړئ، پرته له دې چې په بهرني انټرفېس کې هر سرچینه پرانیزئ۔

د انټرفېس ACL او ssh اجازه سره سمون ورکړئ۔ هغه سبنیټ چې ACL بندوي د هغه لپاره اجازه بیا هم ناکامه کیږي، او هغه ACL چې سبنیټ ته بې له سمون لرونکې ssh ننوتنې اجازه ورکوي په بله دروازه کې ناکامه کیږي۔ دواړه بیانونه یوه لاره له بېلو طبقو څخه تشریح کوي، نو په روانه ترتیب کې یې یوځای وګورئ۔

له نومول شوي هوسټ څخه تایید کړئ، بیا یې بیا تنګه کړئ

له خپل میز څخه نه، بلکې له نومول شوي مدیریت هوسټ څخه نوې سیشن پرانیزئ، او په ASA کې تایید کړئ چې اړیکې کومه سرچینه پته او کوم انټرفېس کارولې۔ تر هغه چې سیشن پرانیستی وي فعال سیشنونه او د روان ترتیب SSH برخه وګورئ، بیا یې وتړئ او هغه هر لنډمهاله اجازه لرې کړئ چې د ازموینې لپاره مو زیاته کړې وه۔ که سیشن ښکاره شي خو د ننوتلو سمدلاسه وروسته ولوېږي، پاتې ستونزه د رسیدو وړتیا نه بلکې اجازه ده۔ د بدلون په ثبت کې انټرفېس او سرچینه ولیکئ ترڅو بل کس تشخیص تکرار نکړي۔

د ټول بدلون په موده کې کنسول یا بله په خپلواک ډول تصویب شوې بیرته راګرځولو لاره شته وساتئ۔ کله چې خصوصي لاره کار وکړ، تایید کړئ چې عامه سرچینو او غیر مربوط VPN کاروونکو ورته لاسرسی نه دی ترلاسه کړی، ځکه چې هغه مدیریت لاره چې د هر چا لپاره کار کوي ستاسو له پیل شوې ستونزې څخه بېله ستونزه ده۔