Публікаванне ўнутранай службы праз VPN паміж сайтамі на ASA

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

Праверка 1: тунель абараняе адрас крыніцы

Пачніце з тунеля, які ўжо прапускае трафік, потым пацвердзіце, што адрас, які вы плануеце апублікаваць, знаходзіцца ўнутры абароненага дыяпазону. На ASA гэты дыяпазон паходзіць з крыпта-ACL або з маршрутаў VTI, і ён мусіць пакрываць рэальны адрас крыніцы, а не падсетку, якую філіял выкарыстоўвае для кіравання. Селектар, які прапускае крыніцу, дае вам тунель, які ўзняты, і паток, які ніколі ў яго не трапляе.

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

Спыніцеся тут, калі абаронены дыяпазон і адрас крыніцы не супадаюць.

Праверка 2: вырашыце, якую крыніцу ўбачыць філіял

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

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

Праверка 3: пішыце трансляцыю пад рэальныя інтэрфейсы

ASA ацэньвае правілы трансляцыі па парадку і паведамляе, якое супала, таму пара інтэрфейсаў унутры правіла не дэкаратыўная. Правіла, напісанае для шляху звонку ўнутр, не супадзе з патокам, у якога ўваход і выхад адрозніваюцца ад тых, што вы меркавалі.

Шлях, які вы будуеце, мае чатыры часткі, і ўсе чатыры мусіць узгадніцца:

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

Праверка 4: абмяжуйце правіла доступу апублікаваным портам

Апублікуйце порт, а не хост. Правіла, якое дазваляе крыніцу на кожнай службе, ператварае адну апублікаваную праграму ў шлях да ўсяго, што запускае крыніца, уключаючы інтэрфейс кіравання, які вы наўмысна трымалі па-за інтэрнэтам. Дазвольце апублікаваны порт ад транслированай крыніцы да крыніцы і пакіньце адміністрацыйныя службы на іх шляху толькі праз VPN.

Праверце парадак правілаў адначасова. Шырокі дазвол, што стаіць над вашым канкрэтным правілам, робіць канкрэтнае правіла нябачным.

Праверка 5: прасачыце адзін запыт і яго адказ

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

packet-tracer input outside tcp 198.51.100.25 50000 203.0.113.20 443 detailed
show nat detail
show xlate
show vpn-sessiondb l2l

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

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