NAT на серверы VPN ці на маршрутызатары? Абодва могуць працаваць

Адзначыць злучэнне як маршрут па змаўчанні на ноўтбуку — гэта крок, які памятаюць усе, і менавіта ён нічога не мяняе на шлюзе. Кліент цяпер адпраўляе інтэрнэт-запыты ў тунэль; ці пакінуць яны будынак, залежыць ад перасылкі, пункта перакладу і зваротнага шляху, які дасягае прыватнага адраса кліента. Дзве схемы могуць забяспечыць усе тры, яны змяшчаюць працу ў розныя месцы, і абедзве адмаўляюць аднолькава ціха, калі ніхто не валодае напрамкам адказу. Выбар паміж імі — пытанне пра тое, хто павінен бачыць пул кліентаў.

Міф: маршрут кліента стварае выхад

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

Гэта неадпаведнасць і ёсць уся праблема, якую вырашае астатняя частка артыкула. Нешта павінна зрабіць прыватны адрас кліента вяртальным, і выбар — дзе.

Спачатку намалюйце шлях адказу

Запішыце шлях з рэальнымі адрасамі, перш чым чапаць налады, і адзначце на ім два магчымыя пункты перакладу. Гэтая лабараторыя выкарыстоўвае пул VPN 10.70.0.0/24 з адным кліентам на 10.70.0.37, адрас LAN сервера 172.16.40.10, маршрутызатар на 172.16.40.1 і публічны выхад 203.0.113.40.

client 10.70.0.37 -- tunnel --> RRAS 172.16.40.10 -- LAN --> router 172.16.40.1 --> 203.0.113.40
                                  (translate here?)                             (or here?)

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

Варыянт A: пераклад на серверы VPN

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

Get-RemoteAccess | Select-Object VpnS2SInterface, RoutingDomain
Get-NetNat | Select-Object Name, InternalIPInterfaceAddressPrefix

Выкарыстайце гэтыя чытанні, каб убачыць, што сервер ужо мае, а не меркаваць, што NAT на месцы. Правіла masquerade у Linux, скапіяванае з блога, — гэта не канфігурацыя Windows, а дазвол у хоставым файрволе для слухача VPN — не тая ж палітыка, што дазвол перасылаць запыт кліента далей. Пацвердзіце ролю перасылкі сервера з яго ўласнай кансолі кіравання, потым паглядзіце на пераклад асобна, бо гэтыя дзве рэчы часта ўключаюцца рознымі часткамі разгортвання.

Варыянт B: перанесці пул на маршрутызатар

У другой схеме сервер перасылае сапраўдны адрас крыніцы кліента, і маршрутызатар перакладае яго. Гэта пакідае пул кліентаў бачным на краі, што дапамагае, калі менавіта маршрутызатар з'яўляецца месцам палітыкі трафіку, журналаў або інспекцыі. Гэта таксама азначае, што маршрутызатару патрэбны зваротны маршрут для 10.70.0.0/24, які паказвае на 172.16.40.10, плюс інтэрнэт-палітыка, якая сапраўды ўключае гэты прэфікс; правіла, напісанае для падсеткі LAN, моўчкі не пашыраецца на пул.

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

Зрабіце DNS, IPv6 і прыёмку відавочнымі

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

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

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