Раздзельнае тунэляванне не пазбаўляе публічны хост правілаў NAT на ASA

Маршрут split-include зацягвае публічны хост у тунэль, дзе ASA павінна зрабіць hairpin і перанесці адрас крыніцы. Прапусціце любы з двух крокаў — і паток абрываецца.

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

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

Міф: раздзельны тунэль прыбірае файрвол з шляху

Перакананне такое: любы пункт прызначэння па-за прыватнымі дыяпазонамі застаецца на лакальным інтэрнэт-злучэнні, таму файрвол яго ніколі не бачыць і ніколі не патрабуе для яго правіла. Гэта слушна толькі датуль, пакуль пункта прызначэння няма ў спісе тунэля. У той момант, калі аператар дадае публічны хост у ACL split-include, кліент накіроўвае гэты трафік у тунэль, і ASA мусіць маршрутызаваць, фільтраваць і пераносіць яго, як любы іншы расшыфраваны паток. На кліенце не змянілася нічога, акрамя спісу пунктаў прызначэння.

Кліент не стаў маршрутызатарам. Ён выканаў палітыку, якую вы яму далі.

Што насамрэч робіць маршрут split-include

У наладзе аддаленага доступу Cisco ASA групавая палітыка змяшчае split-tunnel-policy tunnelspecified і split-tunnel-network-list, які называе стандартны ACL. Кожны радок permit у гэтым ACL — гэта пункт прызначэння, які кліент павінен накіраваць у тунэль, а ўсё астатняе працягвае карыстацца лакальным маршрутам па змаўчанні.

Даданне аднаго хоста — гэта адзін радок, і гэта адзіная частка змены, якую кліент бачыць: access-list RA-SPLIT standard permit host 203.0.113.20.

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

Пакет прыходзіць і сыходзіць праз той жа інтэрфейс

Цяпер прасачыце паток пасля расшыфроўкі. Пакет увайшоў праз знешні інтэрфейс па VPN-тунелі, яго пункт прызначэння — публічны адрас, і табліца маршрутызацыі адпраўляе яго назад праз той жа знешні інтэрфейс у бок інтэрнэту. Трафік, які ўваходзіць і выходзіць праз адзін інтэрфейс, адкідаецца, калі ASA не дазволена яго прапускаць, а менавіта гэта робіць same-security-traffic permit intra-interface. Без гэтага злучэнне падае так, што выглядае як праблема маршрутызацыі, але ёю не з'яўляецца.

Гэты параметр глабальны. Ён дазваляе hairpinning для кожнага патоку, якому гэта патрэбна, а не толькі для гэтага партнёрскага хоста, таму яму месца ў праверанай змене, а не ў хуткім тэсце.

Чаму PAT, абмежаваны пунктам прызначэння, не з'яўляецца неабавязковым

Адрас крыніцы ў расшыфраваным пакеце — гэта па-ранейшаму VPN-адрас кліента, звычайна з пула, такога як 10.77.0.0/24. Гэты адрас не мае маршруту ў публічным інтэрнэце, таму партнёр або не адказвае ніколі, або адказвае ў нікуды.

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

same-security-traffic permit intra-interface

object network RA_POOL
 subnet 10.77.0.0 255.255.255.0
object network PARTNER_HOST
 host 203.0.113.20

nat (outside,outside) source dynamic RA_POOL interface destination static PARTNER_HOST PARTNER_HOST

Частка destination static важная. Калі яе прыбраць, правіла ператворыцца ў шырокі перанос, які можа супасці з куды большым трафікам, чым меркавалася, а шырокае правіла identity, размешчанае раней у парадку, можа цалкам перамагчы гэтае. Праверце show nat detail і парадак раздзелаў, перш чым меркаваць, што супадае менавіта ваша правіла.

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

Дакажыце гэта правільным тэставым пунктам прызначэння

Выкарыстоўвайце сам партнёрскі хост, а не тыповую старонку what-is-my-ip. Гэтая старонка амаль напэўна па-за спісам split, таму яна паведамляе ваш лакальны інтэрнэт-адрас і нічога не кажа пра гэты шлях. Адкрыйце новае злучэнне да партнёрскай паслугі і спытайце, якую крыніцу яны бачылі, або выканайце packet-tracer input outside tcp 10.77.0.10 12345 203.0.113.20 443 detailed і чытайце этапы NAT і маршрутызацыі радок за радком. Traceroute з кліента — слабейшая праверка, бо паказвае шлях, які ўжо адбыўся, а не палітыку, якая яго выбрала.

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

Працоўная версія гэтага дызайну кароткая: адзін хост у split-ACL, дазвол на hairpin, адно правіла PAT, абмежаванае пунктам прызначэння. Усё астатняе ў гэтай гісторыі — міф.

Падобныя артыкулы