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

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