Може ли роаминг VPN клиент да хостира услуга за канцеларијата?

Вашиот канцелариски преносен компјутер може да се приклучи од дома и сепак да служи нешто што на канцеларијата и е потребно, но само кога три одделни одлуки ќе се совпаднат. Тунелот е транспорт, внатрешната адреса е целта, а политиката одлучува кој смее да чука. Ако било која од нив се третира како целиот одговор, се добива познатата жалба: хостот одговара на ping, но апликацијата никогаш не се поврзува. Улогите не се исти и разликата е токму таму каде што живее дизајнерската работа.

Насоката на приклучување не кажува ништо за насоката на услугата

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

Замислете инвентарен систем што анкетира агент на роаминг преносни компјутери, или развивач на кого му треба тест API од работна станица дома. И двајцата сакаат канцелариската страна да го започне разговорот, што е обратно од вообичаената шема клиент-кон-сервер.

Хостираните производи за далечински пристап се разликуваат овде и таа разлика не е дефект. Некои управувани VPN услуги намерно блокираат непобарани поврзувања кон поврзани клиенти бидејќи нивниот модел е клиент-кон-ресурс, а не ресурс-кон-клиент. Прочитајте ја документираната архитектура на производот пред да ветите на колега дека неговиот преносен компјутер може да работи како сервер.

Следете ја повратната патека пред да отворите порта

Патеката има три дела: рута на портата што покажува кон внатрешната адреса на клиентот, политика што го дозволува конкретниот повикувач и услуга што слуша на целта. Секој дел откажува поинаку, затоа «VPN е вклучен» речиси ништо не кажува.

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

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

Имињата и адресите се дизајнерски одлуки

Адресата внатре во тунелот не е автоматски име. Приватен DNS запис што го контролирате е појасен од надежта дека протокол за откривање ќе го премине тунелот, бидејќи локалното multicast разрешување на имиња останува во локалниот сегмент и не станува DNS меѓу подмрежи.

Стабилноста на адресата е исто толку важна. Ако VPN клиентите земаат од базен со кратки закупи, внатрешната адреса на преносниот компјутер се менува меѓу сесиите и секоја обележувачка, огненоѕиден опфат и проверка за надзор изградена врз неа тивко се расипува. Користете резервација или документирана динамична патека за ажурирање.

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

Тестирајте ја услугата, не членството

Од целта потврдете што слуша и на која адреса, потоа потврдете го погледот на портата за повратната патека:

$ ss -ltnp | grep 8080
LISTEN 0 128 10.80.0.23:8080 0.0.0.0:*
$ ip -4 addr show tun0 | grep inet
inet 10.80.0.23/24 scope global tun0
$ ip route get 10.80.0.1
10.80.0.1 dev tun0 src 10.80.0.23

Сега тестирајте од канцелариската страна со вистинско барање наместо ехо. Успешен curl кон услугата го докажува рутирањето, политиката и слушателот одеднаш, додека успешниот ping докажува само дека ICMP е дозволен. Ако барањето не успее, вратете се назад низ трите дела наместо да го проширувате огнениот ѕид и да се надевате.

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

Објавете го ресурсот намерно, со име, список на дозволени повикувачи и сопственик, и далечинскиот уред станува поддржана услуга наместо случаен сервер.