Чаму запыты TACACS+ ад ASA не ідуць праз VPN-тунэль філіяла

Тунэль філіяла працуе, карыстальнікі аўтэнтыфікуюцца на аддаленым серверы TACACS+, а ўласны ўваход на міжсеткавым экране ўсё яшчэ сканчаецца тайм-аўтам. Прычына не ў памылцы тунэля: тунэль LAN-to-LAN перадае трафік, які супадае з яго селектарамі, а кіраўніцкі трафік, які ASA генеруе пра сябе, — гэта асобны паток з уласным адрасам крыніцы. Большасць каманд выяўляе гэта падчас акна змен, калі адзіны ўліковы запіс адміністратара — гэта той, што не працуе. Разглядайце сеанс AAA, які стварае ASA, як паток, які трэба спраектаваць, а не як пабочны эфект злучэння, якое ўжо працуе.

ASA — гэта кліент, і яго ўласны трафік патрабуе ўласнага шляху

Калі міжсеткавы экран звяртаецца да сервера TACACS+, ён з'яўляецца такім жа кліентам, як і любы іншы, з той розніцай, што ніхто наўмысна не наладзіў для яго маршрут. Яго пакеты паходзяць з адрасу інтэрфейсу на прыладзе, яны генеруюцца лакальна, а не перасылаюцца, і іх трэба маршрутызаваць, трансляваць і абараняць палітыкай гэтак жа, як трафік карыстальнікаў. Тунэль паміж пляцоўкамі, які абараняе падсетку карыстальнікаў, не абараняе аўтаматычна гэтую кіраўніцкую крыніцу, бо выбар трафіку грунтуецца на адрасах, а не на намерах.

Запішыце адрас, які, як вы чакаеце, убачыць сервер. Калі вы не можаце сфармуляваць яго ў адзін радок, дызайну ў вас яшчэ няма.

Інтэрфейс у радку aaa-server — гэта не ўпрыгожанне

На ASA запіс хоста aaa-server прымае прывязку да інтэрфейсу ў дужках, і даведнік па камандах хоста AAA ад Cisco апісвае яго як інтэрфейс, на якім знаходзіцца сервер аўтэнтыфікацыі. Менавіта гэтая прывязка звязвае запыт з інтэрфейсам і з палітыкай, якую гэты інтэрфейс прымяняе. Выбар яго па тым інтэрфейсе, які глядзіць у інтэрнэт, або захаванне таго, што засталося ад апошняй міграцыі, дае адрас крыніцы, для якога аддалены сервер і тунэль ніколі не будаваліся.

inside — правільны адказ толькі тады, калі названы інтэрфейс утрымлівае адрас, які ваш дызайн мае намер выкарыстоўваць як крыніцу. На прыладзе філіяла гэта часта так; на прыладзе з некалькімі прыватнымі сегментамі — магчыма, не.

Змена прывязкі азначае перастварэнне запісу

Той жа даведнік па камандах дакументуе абмежаванне рэдагавання, якое ловіць людзей падчас пераходаў: змена інтэрфейсу ў існуючага хоста патрабуе выдалення і перастварэння запісу хоста. Канфігурацыя, якая выглядае адрэдагаванай, магла не ўступіць у сілу, і наступная спроба ўваходу ўсё яшчэ пойдзе са старога адрасу. Плануйце гэта як выдаленне і даданне з копіяй арыгінальнага запісу перад вачыма, а не як праваку на месцы.

Калі вызначана некалькі сервераў, змяніце адзін і праверце яго, перш чым чапаць астатнія, каб памылка не заблакавала ўсе адміністрацыйныя шляхі адразу.

Правярайце селектары, трансляцыю і зваротны шлях разам

Тры рэчы павінны ўзгадніцца, каб запыт дайшоў. Селектары трафіку тунэля, або абарона інтэрфейсу тунэля, калі вы яе выкарыстоўваеце, павінны ўключаць уласную крыніцу ASA і адрас сервера; спіс селектараў, пабудаваны для падсетак карыстальнікаў, звычайна гэтага не зробіць. Любое правіла NAT на шляху павінна паслядоўна трансляваць гэтую крыніцу, бо сервер аўтарызуе ідэнтычнасць сеткавай прылады, якая ўключае адрас, што ён бачыць. І зваротны шлях павінен існаваць, што для тунэля на аснове палітык азначае наяўнасць у далёкага боку адпаведнага селектара ў іншым кірунку.

На баку сервера асобна пацвердзіце ідэнтычнасць прылады, агульны сакрэт і адміністрацыйную палітыку. TACACS+ трымае аўтэнтыфікацыю, аўтарызацыю і ўлік як асобныя аперацыі, таму адмова, якая прыходзіць пасля завершанага абмену, — гэта адказ палітыкі, а не збой транспарту. Калі чытаць яе як сеткавую праблему, вы будзеце шукаць не там.

Трымайце сакрэт па-за перахопамі, тыкетамі і транскрыптамі падчас адладкі, і памятайце, што адрас крыніцы, які сервер запісвае ў журнал, — гэта той, які ваш дызайн павінен патлумачыць.

Зрабіце змену, не заблакаваўшы сябе

Выкарыстоўвайце кансоль або незалежны шлях кіравання, пакуль змяняеце аддаленую адміністрацыйную аўтэнтыфікацыю, і трымайце зацверджаны лакальны рэзервовы варыянт, пакуль новы шлях не правядзе рэальны ўваход. Затым праверце вузка: адзін сервер, адна прылада, адна паспяховая аўтэнтыфікацыя з адрасам крыніцы, назіраным на абодвух баках.

Запішыце паток на яго ўласнай старонцы: інтэрфейс і адрас крыніцы, аддалены сервер, абаронены шлях і чалавек, які валодае палітыкай аўтарызацыі. Тады пазнейшую змену інтэрфейсу або тунэля можна будзе ацаніць, не ўгадваючы, якога з двух патокаў яна датычыцца.