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 клиентите имат маршрут, валиден публичен източник или политика, която ги блокира, когато тунелът падне. Оставянето на това неизказано означава, че половината клиенти тихо заобикалят шлюза, докато другата половина работят.

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