Върнете маршрут към VPN за LAN хостове с DHCP опция 121

Отдалечени VPN клиенти се свързват, LAN сървърът отговаря и отговорът излиза през обичайния интернет рутер и умира там. Един сървър може да се поправи със статичен маршрут, но цяла подмрежа от тях е по-добре да се управлява там, където те вече получават мрежовата си конфигурация. DHCPv4 опция 121 разпространява точно такъв маршрут до дестинация и това е частта, която хората обикновено объркват в момента, в който забравят маршрута по подразбиране. Симптомът е еднопосочен трафик: заявките пристигат, а отговорите изчезват.

Първо назовете трите адреса

Вземете конкретна LAN: 192.168.50.0/24 с обичайния рутер по подразбиране на 192.168.50.1 и отделен VPN шлюз на 192.168.50.2. Удостоверените отдалечени клиенти заемат 10.90.0.0/24.

Маршрутът, от който се нуждае всеки участващ хост, е 10.90.0.0/24 via 192.168.50.2. Дестинацията е пулът от клиенти, а следващият хоп е LAN адресът на шлюза, а не адресът му в тунела.

Кодирайте го като безкласов статичен маршрут

Опция 121 носи двойки префикс и следващ хоп, а RFC 3442 дефинира както кодирането, така и поведението на клиента, което следва. За съществуващ екземпляр на dnsmasq, обслужващ само тази илюстративна LAN, формата на конфигурацията е:

dhcp-option=121,10.90.0.0/24,192.168.50.2,0.0.0.0/0,192.168.50.1

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

Не губете маршрута по подразбиране

Това е капанът. Клиент, който получи опция 121, трябва да игнорира обичайната опция Router, така че обявяването само на маршрута до пула VPN може да остави този хост напълно без маршрут по подразбиране. Машината все още изглежда конфигурирана и тихо губи интернет. Потребителите описват това като това, че мрежата е паднала, докато всеки интерфейс е вдигнат.

Включете желания маршрут по подразбиране в същия списък, както прави фрагментът по-горе. Запазете и обичайната опция Router за клиенти, които не реализират безкласови маршрути; собствената обработка на опции от сървъра решава какво и на кого се изпраща.

Проверете какво ще приеме клиентът

Хост с ръчно зададен адрес никога не прихваща това, защото не иска наем. Поддръжката при клиентите също варира, затова тествайте на операционната система, която наистина използвате, вместо да предполагате, че всяко устройство зачита опция 121. Потвърдете с тези, които притежават сървърите, кои от тях са със статични адреси. Тези хостове се нуждаят от собствени записи за маршрут, иначе просто няма да участват.

Управляваните DHCP услуги са друго ограничение. Някои облачни мрежи не позволяват на администраторите да публикуват произволни опции, а конкурентен DHCP сървър в същия сегмент е по-лош от липсата на опция изобщо.

Проверете наема, после търсенето

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

На Linux клиент прочетете действителните маршрути и потвърдете двата записа:

ip -4 route
ip -4 route get 10.90.0.23

Контекстното търсене трябва да покаже маршрута до пула през 192.168.50.2 и маршрута по подразбиране през 192.168.50.1. Ако маршрутът по подразбиране липсва, възпроизвели сте капана по-горе.

След това тествайте реалния обмен

Разпространението на маршрути не е целият път. Отделният шлюз все още се нуждае от препращане, собственост върху отдалечените партньори и политика за достъп, която разрешава сървъра, а DHCP не удостоверява никого.

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