Достъп до работна станция зад NAT без пренасочване на порт

Две крайни точки зад NAT на оператора и заключен офис рутер не оставят входящ порт за пренасочване, а рефлексът е все пак да поискаме такъв. По-добрият въпрос е коя страна може да излиза навън и кой достъпен сервиз има право да носи трафика. Четири решения отговарят на този въпрос по различен начин и се провалят по различен начин, когато пътят е блокиран. Изборът между тях е сравнение на гаранции, а не на имена на протоколи.

Четири решения, четири различни обещания

Таблицата по-долу е кратката версия. Четете средната колона като обещанието, което можете да проверите, а дясната колона като обещанието, което никой не е дал.

Кой ред е приложим зависи от задачата, а не от предпочитанието. Една сесия за отдалечен работен плот, една административна конзола и достъп до цяла частна подмрежа са три изисквания, които не се нуждаят от една и съща входна точка, дори когато случайно засягат една и съща машина.

Хъбът променя кой излиза навън, а не какво е разрешено

При решение с маршрутизиран хъб отдалеченият лаптоп и работната станция, или шлюзът на обекта пред нея, всяко отваря изходящ тунел към сервиз, достъпен и за двете страни. Нищо не приема непоискана връзка на рутера на работната станция и точно затова това решение оцелява зад NAT и работи, когато обектът няма статичен адрес. След това хъбът маршрутизира трафика между двата вътрешни адреса според собствената си политика.

Цената е, че хъбът трябва да съществува, да е достъпен от двете страни и някой да го управлява. Филтрирането на изходящия трафик трябва да разрешава транспорта, а мрежа, която го блокира, ще провали решението, дори да не е било нужно пренасочване на порт.

Тънката част е, че достъпността и оторизацията са отделни решения, взети на различни места. Маршрут към префикс не казва нищо за това кой сервиз на работната станция може да ползва самоличността, а правило на защитна стена, което разрешава тунела, не казва нищо за това дали акаунтът може да влезе. Конфигурирайте и двете, тествайте и двете и оставете решението за оторизация при системата, която притежава ресурса, а не при таблицата за маршрутизация.

Проникването работи само когато и двата стека го реализират

Проникването между равностойни възли е възможност на конкретна система, а не настройка, която подобрява VPN. Interactive Connectivity Establishment събира няколко кандидат-адреса и тества двойки, докато една проработи: кандидати на хоста по локалните интерфейси, сървърно-рефлексивни кандидати, изградени от това, което разкрива NAT, и релейни кандидати, отпуснати на релей. Частният адрес сам по себе си не е път, защото другата страна не може да маршрутизира до него.

Релейният случай си струва да се разбере, преди да бъде отхвърлен. RFC 8656 описва TURN като протокол, при който клиентът иска от сървър релейен транспортен адрес, а сървърът препраща трафик между този клиент и неговите равностойни възли. Затова релеят носи данните, което е съществено различно от директория, която само помага на крайните точки да се срещнат. Размяната на релейния адрес с другата страна е стъпка за координация, която приложението трябва да изпълни.

Това, което не можете да обещаете, е директен път. Симетричният NAT и някои корпоративни защитни стени провалят пробиването на дупки и когато това стане, системата или преминава към релей, или се проваля. Не можете също да заключите, че два транслационни крайни точки никога не могат да говорят; поддържан стек с релейно резервно решение съществува точно защото често могат. Решете дали наличността или директността е по-важна, после проверете кой път всъщност е избрало внедряването, вместо да предполагате благоприятния случай.

Брокерът е по-тесен от мрежата

Когато изискването е едно приложение, брокер на приложения или обратна връзка, стартирана от работната станция, може да е най-малкият отговор. Работната станция излиза навън към брокер, брокерът удостоверява отдалечения потребител и се пренася само онази сесия на приложението. Не се създава маршрут към подмрежата на работната станция, така че компрометиране на отдалечената сесия не наследява път до всяко устройство до нея.

Тази теснота има цена: всяко допълнително приложение се нуждае от собствена интеграция и всичко, което приложението предполага за локална мрежа, например файлов дял, който отваря на близък сървър, може да е недостъпно. Брокерите също концентрират политика и журналиране на едно място, което е полезно, докато това място не стане прекъсването.

Сравнете границите на доверие, после тествайте пътя

Хъб, който прекратява тунели, може да чете трафика, който маршрутизира. Релеят може да носи независимо защитен обмен, когато приложението криптира от край до край, а брокерът обикновено прекратява сесията, която представя. Установете къде защитата всъщност свършва, преди да решите, че две решения са еквивалентни, защото и двете са криптирани.

После проверете до какво работната станция всъщност достига навън, тъй като всяко решение по-горе зависи от това. Изпълнете това на работната станция, като замените името на хоста, което смятате да използвате.

ss -lntup
nc -vz hub.example.com 443
curl -sS -o /dev/null -w "%{http_code}\n" https://hub.example.com

Приемете решението само след като желаната отдалечена операция успее под разрешената самоличност, неодобрена самоличност бъде отказана и поведението при недостъпен директен или релеен път е известно и документирано. Включете повторно свързване и нормалния контекст на стартиране на работната станция, защото сесия, започнала в офиса през LAN, не тества нищо, от което зависи отдалеченият достъп.