DHCP-рэлей ASA праз VPN сайт-сайт: практычны разбор

Рэлей працуе ў тры этапы, і толькі сярэдні перасякае VPN. Кліент шырокавяшчае на сегменце філіяла, ASA ператварае гэтае шырокавяшчанне ў адрасны запыт да сервера DHCP, а сервер адказвае на адрас рэлея, а не кліента. Прайдзіце этапы менавіта ў гэтым парадку, і большасць выпадкаў «рэлей зламаны» зводзіцца да адсутнай палітыкі або няправільна прачытанага радка setroute.

Этап першы: уключыць рэлей на інтэрфейсе, які глядзіць на кліентаў

На ASA філіяла рэлей — гэта ўласцівасць інтэрфейса, які глядзіць на кліентаў. Сервер можна аб’явіць глабальна з яго дасяжным інтэрфейсам або пад гэтым кліенцкім інтэрфейсам, каб табліца маршрутызацыі выбрала выхад. Гэтыя дзве формы не ўзаемазаменныя, і капіраванне няправільнай — першае месца, дзе разбор ідзе набакос.

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

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

Этап другі: правесці трафік, створаны ASA, праз тунель

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

Пераканайцеся, што цікавы трафік ахоплівае крыніцу рэлея ASA і адрас сервера, а зваротны кірунак таксама дазволены. У схеме на аснове VTI рашэнне аб маршруце прасцейшае, але падтрымка рэлея праз VTI з’явілася ў пэўным рэлізе; кіраўніцтва ASA па DHCP паказвае 9.14(1), таму праверце вобраз, перш чым пераносіць прыклад VTI на старэйшую прыладу.

Ping з ASA да сервера сам па сабе мала што даказвае. Ён можа прайсці праз іншы шлях, з іншага адраса крыніцы або пад палітыкай, якой пакеты рэлея не адпавядаюць.

Этап трэці: прачытаць адказ і опцыю setroute

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

Затым раздзяліце дзве рэчы, якія гучаць падобна. Ключавое слова setroute змяняе або дадае опцыю маршрутызатара па змаўчанні, якую ASA перадае кліенту. Яно не ўсталёўвае маршрут на ASA і не стварае палітыку VPN. Кліент, які атрымаў адрас, але нічога не дасягае, часта мае праблему setroute або scope, а не праблему тунеля. Праверце гэта на кліенце без статычнага шлюза і паглядзіце, які маршрутызатар па змаўчанні з’явіцца ў прапанове.

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

Што я правяраю, перш чым назваць гэта выпраўленым

Пачніце з кліента і захапіце шырокавяшчанне, затым пераканайцеся, што ASA перадала яго са сваім адрасам як giaddr. На далёкім баку пераканайцеся, што сервер убачыў гэты запыт і выбраў scope, які адпавядае філіялу. Вярнуўшыся ў філіял, пераканайцеся, што кліент прыняў прапанову і дасягае свайго шлюза.

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

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