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

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

Смер повезивања не говори ништа о смеру услуге

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

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

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

Пратите повратни пут пре него што отворите порт

Пут има три дела: руту на gateway-у која показује на унутрашњу адресу клијента, политику која допушта конкретног позиваоца и услугу која слуша на циљу. Сваки део затаји другачије, зато „VPN ради“ не говори готово ништа.

Добра вест је да унутрашњи пут не треба прослеђивање порта на клијентовом кућном рутеру. Управо је то смисао објављивања услуге на адреси тунела уместо на кућној WAN адреси, где би изложеност и NAT правила била сасвим другачија. Кућни рутер може и да одбије hairpin везе која долази из канцеларије, па WAN рута затаји из разлога неповезаних са вашим VPN-ом. Држање саобраћаја унутар тунела избегава оба проблема одједном.

Проверите и страну циља. Услуга везана само за 127.0.0.1 не може прихватити везу која долази на интерфејс тунела, колико год gateway руте биле исправне. Правило host firewall-а које допушта порт само са локалне подмреже такође ће одбацити канцеларијски саобраћај, а то правило је независно од VPN политике изнад њега.

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

Адреса унутар тунела није аутоматски име. Приватни DNS запис који контролишете јаснији је од наде да ће протокол за откривање прећи тунел, јер link-local multicast разрешавање имена остаје на локалном сегменту и не постаје DNS између подмрежа.

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

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

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

Са циља потврдите шта слуша и на којој адреси, затим потврдите како gateway види повратни пут:

$ 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 дозвољен. Ако захтев не успе, идите уназад кроз три дела уместо да ширите firewall и надате се.

Доступност припада истом разговору. Лаптоп спава, роаминг између мрежа и искључује се на крају дана. Услуга која мора да одговори у свако доба припада стално укљученом host-у, док услуга по принципу најбољег труда може остати на клијенту уз записано ограничење.

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