DHCP релей на ASA през VPN сайт-към-сайт: практическо ръководство

Релеят работи на три етапа и само средният пресича VPN. Клиентът излъчва в сегмента на клона, ASA превръща това излъчване в едноадресна заявка към DHCP сървъра, а сървърът отговаря на адреса на релея, а не на клиента. Проследете етапите в този ред и повечето случаи на „релеят е счупен“ се свеждат до липсваща политика или погрешно прочетен ред setroute.

Етап първи: включване на релея на интерфейса към клиентите

На ASA в клона релеят е свойство на интерфейса, който гледа към клиентите. Сървърът може да се обяви глобално с достижимия си интерфейс или под този клиентски интерфейс, за да избере маршрутната таблица изхода. Тези две форми не са взаимозаменяеми и копирането на грешната е първото място, където ръководството поема накриво.

Проверете текущата конфигурация, преди да промените нещо: кой интерфейс има включен релей, коя форма на сървъра присъства и дали setroute е прикачен към клиентския интерфейс. Ако ASA изпълнява и DHCP сървър за друг сегмент, спрете и прочетете списъка с ограничения; сървър и релей не могат да са включени едновременно на една и съща машина.

Релеят поставя собствения си клиентски адрес в полето за адрес на шлюза. Именно на този адрес ще отговаря сървърът, затова той трябва да е достъпен от далечния сайт през тунела, не само локално.

Етап втори: пренасяне на генерирания от ASA трафик през тунела

Това е стъпката, която хората пропускат. VPN сайт-към-сайт, базиран на политики, обикновено се изгражда за трафик между подмрежи, а заявката за релей се генерира от самата ASA. Ако списъкът за достъп на тунела и крипто картата съвпадат само с потоци от хост в клона към подмрежата на сървъра, пакетът на релея може никога да не влезе в тунела. Проверете списъка за достъп в двете посоки, не само реда от клона към сървъра.

Потвърдете, че интересният трафик покрива източника на релея на ASA и адреса на сървъра, и че обратната посока също е разрешена. При дизайн на базата на VTI маршрутното решение е по-просто, но поддръжката на релей през VTI дойде в конкретна версия; ръководството за DHCP на ASA посочва 9.14(1), затова проверете изображението, преди да копирате пример за VTI на по-стар апарат.

Ping от ASA до сървъра сам по себе си доказва малко. Той може да успее по друг път, с друг адрес на източника или при политика, на която пакетите на релея не отговарят.

Етап трети: прочитане на отговора и опцията setroute

RFC 2131 казва, че сървърът изпраща отговора си на адреса в giaddr, когато това поле е различно от нула. Следователно обратният път трябва да маршрутизира към адреса на релея, а тунелната политика трябва да разрешава посоката от сървъра към релея. Ако заявката е преминала, но предложението така и не пристигне, тук е мястото за проверка.

След това разграничете две неща, които звучат еднакво. Ключовата дума setroute променя или добавя опцията за маршрутизатор по подразбиране, която ASA дава на клиента. Тя не инсталира маршрут на ASA и не създава VPN политика. Клиент, който получава адрес, но не достига до нищо, често има проблем със setroute или обхвата, а не с тунела. Тествайте с клиент без статичен шлюз и наблюдавайте кой маршрутизатор по подразбиране се появява в предложението.

Прочетете предложението от начало до край: предложен адрес, маска, маршрутизатор по подразбиране, DNS и срок на наема. След това оставете наема да се поднови. Релей, който работи веднъж и се проваля при подновяване, обикновено има проблем с обхват, наем или обратен път, който първият обмен е скрил.

Какво проверявам, преди да го обявя за оправено

Започнете от клиента и уловете излъчването, след което потвърдете, че ASA го е препратил със собствения си адрес като giaddr. От далечната страна потвърдете, че сървърът е видял тази заявка и е избрал обхват, който съответства на клона. Обратно в клона потвърдете, че клиентът е приел предложението и достига до шлюза си.

Ако някой етап е безмълвен, проверете съответната политика или маршрут, вместо да добавяте още един ред за релей. Конфигурацията на релея обикновено е вярна до момента на ескалация; променили са се тунелната политика или обратният маршрут.

Запишете трите етапа в записа за промени: клиентски интерфейс, VPN политика, покриваща релейния трафик, и маршрута на сървъра обратно към giaddr. Този запис прави следващото изграждане на клон повтаряема задача, а не сесия за отстраняване на грешки. Той също казва на следващия инженер кой изход от команда да събере първо.