Корисник на порта во Access Server: рутирање на LAN на огранок на клиент
Во Access Server адресата на тунелот на клиентот не е рута до неговиот огранок. Декларирајте го корисникот порта, потоа поправете ги двата повратни патишта и препраќањето.
Може да ping-увате адреса на тунел на 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 до домаќин во огранокот, потоа истата услуга од обичен домаќин во централата, потоа обратната насока ако политиката дозволува. Ако првото помине, а второто не, проблемот се испратените рути или правилата за пристап. Ако двете поминат, но одговори не пристигнуваат, проверете го препраќањето во огранокот и повратната рута во централата.
Следен сомнителен е firewall-от на домаќинот, бидејќи при рутиран пристап дестинацијата гледа адреса на централата или базенот како извор. Правило напишано за локалната подмрежа нема да се совпадне и пакетот се отфрла.
Два дизајна бараат повеќе. Префиксите што се преклопуваат меѓу локациите ја прават дестинацијата двосмислена и бараат пренумерување или превод, а кластериран Access Server бара секој јазол да има работен пат до конекторот на огранокот, а не еден јазол што ја држи рутата. Применете ги промените преку вообичаениот пат за зачувување и ажурирање, поврзете го конекторот повторно и проверете од двата краја; целосно рестартирање на секој компјутер не е дел од постапката.
Упатството site-to-site на Access Server ги наведува истите поставки по редослед на производот; вреди да се следи еднаш пред да се прилагоди дизајнот на сопствените префикси.