Објављивање унутрашње услуге преко ASA VPN-а између локација

Објављивање услуге која живи иза 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-а је погрешан. Ако показује одбијање, редослед правила је погрешан. Ако стигне до тунела али извор никада не одговори, проблем је пут повратка огранка.

Затим пошаљите један стварни захтев споља и потврдите да се одговор враћа кроз исти тунел. Забележите објављени унос, превод, заштићени пар адреса и руту повратка као запис о објављивању.