Карыстальнік шлюза 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 forwarding у яго АС плюс дазвол перасылкі, абмежаваны інтэрфейсамі тунеля і LAN; у Linux гэта net.ipv4.ip_forward=1 разам з правіламі forward chain, у Windows — routing and remote access. Затым хостам філіяла патрэбны зваротны шлях: альбо злучальнік — іх шлюз па змаўчанні, альбо існуючы шлюз нясе канкрэтныя маршруты для прэфіксаў галаўнога офіса і пула.

Уласная табліца маршрутызацыі злучальніка не пераналаджвае кожны хост у LAN філіяла. Калі хасты паказваюць на іншы маршрутызатар, зваротныя маршруты належаць там, і ён павінен прымаць, што адрас крыніцы, які ён бачыць, не з’яўляецца суседам у лакальнай падсетцы.

Чытайце збой як шлях, а не як дазвол

Тэстуйце ў фіксаваным парадку. Спачатку дазволены сэрвіс ад Access Server да хоста філіяла, потым той жа сэрвіс ад звычайнага хоста галаўнога офіса, потым зваротны кірунак, калі палітыка дазваляе. Калі першы праходзіць, а другі не, праблема ў адпраўленых маршрутах або правілах доступу. Калі абодва праходзяць, але адказы не прыходзяць, праверце перасылку ў філіяле і зваротны маршрут у галаўным офісе.

Наступны падазроны — файрвол хоста, бо пры маршрутызаваным доступе прызначэнне бачыць крыніцай адрас галаўнога офіса або пула. Правіла, напісанае для лакальнай падсеткі, не супадзе, і пакет скідаецца пасля таго, як маршрутызацыя цалкам спрацавала.

Дзве схемы патрабуюць большага. Прэфіксы, што перакрываюцца паміж пляцоўкамі, робяць прызначэнне няпэўным і патрабуюць перанумарацыі або трансляцыі, а кластарны Access Server патрабуе працоўнага шляху ад кожнага вузла да злучальніка філіяла, а не аднаго вузла з маршрутам. Ужывайце змены звычайным шляхам захавання і абнаўлення, перападключыце злучальнік і праверце з абодвух бакоў; поўная перазагрузка ўсіх машын не ўваходзіць у працэдуру.

Падручнік Access Server па злучэнні сайт-сайт пералічвае тыя ж налады ў парадку прадукту; варта прайсці яго адзін раз, перш чым адаптаваць схему да сваіх прэфіксаў.