SoftEther зад NAT: директно пробивање или VPN Azure реле?

Динамичниот DNS, пробивањето на NAT и VPN Azure вршат различни работи. Изберете ја патеката пред да уредувате корисници, потоа потврдете кој транспорт сесијата навистина го користи.

Вашиот SoftEther сервер стои зад рутер на давателот што не можете да го промените, а клиентите сѐ уште се поврзуваат, па претпоставувате дека реле пренесува сѐ. Дали тоа е точно зависи од тоа кој механизам ја извршил работата: DNS име, координирана UDP патека или излезен тунел до реле. Сите три можат да дадат поврзан клиент и тие пропаѓаат во различни услови. Одлучете која патека ја купувате пред да допрете корисници или концентратори.

Три механизми, три различни ветувања

Динамичниот DNS е именување. Тоа го држи името на домаќинот насочено кон адреса што се менува за да престанат луѓето да го бркаат бројот, и не прави ништо друго. Вроденото пробивање на NAT е координација: две SoftEther крајни точки разменуваат информации и се обидуваат да отворат употреблива UDP патека низ уредите за превод меѓу нив. VPN Azure е реле: серверот се поврзува кон услугата, а клиентите доаѓаат преку име на домаќин во инфраструктурата на релето.

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

Одлучете според клиентот и мрежата

Изборот започнува кај клиентот, бидејќи пробивањето постои само во вродениот SoftEther механизам за поврзување. OpenVPN, L2TP/IPsec и SSTP слушатели на истиот сервер не го наследуваат, иако делат домаќин. Погледнете што ќе извршува корисникот, потоа што дозволува мрежата. Корпоративна мрежа што дозволува само TCP 443 ве турка кон реле на тој порт, додека мрежа што ги пропушта UDP портите потребни за пробивање може да опита директна патека; потврдете ги двете спрема вистинската политика за излез.

Рачно достапен слушател сѐ уште е легитимен дизајн кога администратор може да објави еден, но тоа е одделен проект со сопствено адресирање и работа на ѕидот за заштита.

Потврдете кој транспорт го избра сесијата

Состојбата на врската е единствениот чесен извор за патеката што се користи. Прочитајте ја на серверот и разрешете го името на домаќинот што го доби клиентот.

vpncmd /SERVER localhost /HUB VPN /CMD:SessionList
vpncmd /SERVER localhost /HUB VPN /CMD:SessionGet <session-name>
nslookup alice.vpnazure.net

SessionList покажува кои сесии се поврзани, а SessionGet на една од нив го известува типот на врска, вклучително и дали сесијата пристигнала преку релето. Запис што се разрешува на инфраструктурата на релето ви кажува дека сесијата поминува низ трета страна, што можете да го потврдите со блокирање на таа рута во тест. Со вроден клиент, UDP забрзувањето може да ја оддалечи патеката на податоци од контролната патека, па едно набљудување не ја опишува целата сесија. Застарено динамично DNS име по промена на адреса, и реле што одговара додека патеката кон бекендот недостасува, се два режима на откажување што вреди да се тестираат одделно. Запишете што сте измериле, а не што имал намера дизајнот.

Планирајте од што зависи избраната патека

Секоја патека носи зависност. Директното пробивање може да се промени по мрежен премин или нов уред за превод, додека сесијата преку реле пропаѓа кога ќе пропадне услугата или нејзината достапна порта. Поврзете се повторно од друга мрежа и потврдете го идентитетот на серверот што клиентот го проверил, држејќи ја претходно работната патека во истиот тест. Потоа тестирајте го приватниот ресурс зад VPN, бидејќи авторизацијата, членството во концентраторот, доделувањето адреси и повратните рути во секој случај остануваат ваша одговорност.

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

Поврзани статии