Потребител-шлюз в Access Server: маршрутизиране на LAN в клона на клиент

Можете да пингувате адреса на тунела на клиент OpenVPN и пак да не достигнете нито един хост в LAN зад него. Access Server дава на клиента адрес от VPN пула и адресът от пула е единственото, което сървърът знае, че притежава. Префиксът на клона е отделен факт, който трябва да се декларира, и дори след това клонът се нуждае от препращач, а централата — от обратен път. Маршрут, въведен на грешното място, изглежда като решение и не променя нищо.

Два адреса, две различни претенции за собственост

При свързване Access Server дава на клиента адрес от конфигурирания VPN пул, например 10.90.0.0/24. Това назначение е наем за един хост. Нищо в свързването не казва, че същият клиент стои и пред 10.60.0.0/24, и сървърът няма да гадае: LAN префикс е достъпен през конкретен клиент само ако администратор го декларира.

Затова статичен маршрут на друга машина не помага. Маршрутът казва: изпращай 10.60.0.0/24 към този адрес, но ако адресът принадлежи на клиент, който не е отбелязан като шлюз, сървърът няма причина да доставя тези пакети там, а стекът на клиента може да ги изхвърли. Декларацията и маршрутът са две половини на един механизъм.

Какво всъщност инсталира настройката за шлюз

В Admin Web UI декларацията е свойство на потребителя: включете Configure VPN gateway на потребителя-конектор и въведете реалния префикс на клона в Network on the VPN client side. Този потребител се удостоверява като всеки друг, затова му трябва политика за идентификационни данни, подходяща за устройство без надзор, а профилът за автоматичен вход е тайна, не файл за удобство.

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

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

Завършете обратните пътища на двете мрежи

Конкретен план: централа 10.40.0.0/24, клон 10.60.0.0/24, VPN пул 10.90.0.0/24, а Access Server е достъпен на частен адрес от страната на централата. Рутерът на централата се нуждае от маршрути за префикса на клона и за пула, и двата към Access Server. Без тях тунелът носи заявката, а отговорът излиза през шлюза по подразбиране, което дава класическата полуотворена връзка.

В клона конекторът трябва да препраща пакети, които не са адресирани до него: IP препращане в операционната система плюс разрешение за препращане, ограничено до интерфейсите на тунела и LAN; в Linux това е net.ipv4.ip_forward=1 заедно с правилата във forward веригата, в Windows — routing and remote access. След това хостовете в клона се нуждаят от обратен път: или конекторът е шлюзът им по подразбиране, или съществуващият шлюз носи конкретни маршрути за префиксите на централата и пула.

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

Четете отказа като път, не като разрешение

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

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

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

Урокът на Access Server за връзка сайт-сайт изброява същите настройки в реда на продукта; заслужава едно следване, преди да адаптирате дизайна към своите префикси.