DHCP релеј на ASA преку VPN од локација до локација: практичен водич

Релејот работи во три етапи и само средната ја преминува VPN-та. Клиентот емитува broadcast на сегментот на подружницата, ASA го претвора тој broadcast во unicast барање до 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 и време на закуп. Потоа оставете закупот да се обнови. Релеј што работи еднаш, а паѓа при обновување, обично има проблем со опсег, закуп или повратен пат што првата размена го сокрила.

Што проверувам пред да кажам дека е поправено

Започнете од клиентот и фатете го broadcast-от, потоа потврдете дека ASA го препратил со својата адреса како giaddr. На далечната страна потврдете дека серверот го видел барањето и избрал опсег што одговара на подружницата. Враќајќи се во подружницата, потврдете дека клиентот ја прифатил понудата и ја достигнува својата порта.

Ако некоја етапа е тивка, проверете ја соодветната политика или рута наместо да додадете уште една релејна изјава. Релејната конфигурација обично е веќе точна кога некој ќе ескалира; се променила тунелската политика или повратната рута.

Запишете ги трите етапи во записот за промени: интерфејс кон клиентите, VPN политика што го покрива релејниот сообраќај и повратната рута на серверот до giaddr. Токму тој запис ја прави следната изградба на подружница повторлива работа наместо сесија за отстранување грешки. Тој му кажува и на следниот инженер кој излез од команда прво да го собере.