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

За прихватање, пратите један дозвољени захтев клијента и његов одговор кроз обе границе и запишите коју адресу свака граница треба да види у том тренутку. Тај запис је оно што следећу промену пула чини петоминутном изменом уместо расправом о томе ко поседује недостајућу повратну руту. Чувајте запис уз профил клијента, а не у тикету, јер профил је оно што ће следећи инжењер прво наћи.