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 або з областю дії, а не з тунелем. Перевірте це на клієнті без статичного шлюзу й подивіться, який маршрутизатор за замовчуванням з'явиться в пропозиції.

Прочитайте пропозицію від початку до кінця: запропонована адреса, маска, маршрутизатор за замовчуванням, DNS і термін оренди. Потім дайте оренді поновитися. Ретрансляція, яка працює один раз і збоїть під час поновлення, зазвичай має проблему з областю дії, орендою або зворотним шляхом, яку приховав перший обмін.

Що я перевіряю, перш ніж сказати, що виправлено

Почніть із клієнта й захопіть широкомовлення, потім переконайтеся, що ASA передала його зі своєю адресою як giaddr. На віддаленому боці переконайтеся, що сервер побачив цей запит і вибрав область, яка відповідає філії. Повернувшись у філію, переконайтеся, що клієнт прийняв пропозицію й досягає свого шлюзу.

Якщо якийсь етап мовчить, перевірте відповідну політику або маршрут, замість додавати ще одну інструкцію ретрансляції. Конфігурація ретрансляції зазвичай уже правильна на момент ескалації; змінилися тунельна політика або зворотний маршрут.

Запишіть три етапи в журнал змін: інтерфейс з боку клієнтів, політику VPN, що охоплює трафік ретрансляції, і зворотний маршрут сервера до giaddr. Саме цей запис робить наступну побудову філії повторюваною роботою, а не сеансом налагодження. Він також каже наступному інженеру, який вивід команди зібрати першим.