Дано:
1 - Выделенный сервер со статическим IP адресом (далее "тип 1").
2 - Некоторое кол-во компьютеров (далее "типа 2") с непредсказуемыми способами выхода в интернет,
и на них, на различных портах, работают некоторые службы.
Для примера предположим, что это стандартный набор HTTP, POP3, SMTP.

Но зайти на эти порты из интернет невозможно, т.к. заранее не известен
ни их IP адрес, ни время "выхода в эфир" И, разумеется, на компьютерах (типа 2)
настроен FireWall для разрешения входящих соединений только из локальной сети или 127.0.0.1
И не настроен проброс этих портов на маршрутизаторах (или прокси серверах)
через которые они выходят в интернет.

Задача:
Нужно получить доступ к портам на компьютерах (типа 2) из интернет или с других компьютеров (типа 2)

Вариант решения:
На компьютерах (типа 2) запускаем программу, которя открывает 2 клиентских сокета для исходящих соединений:

Первое соединение - в направлении 127.0.0.1:80 - какой-то актуальный порт для работы (напр. последний использовавшийся)
Второе соединение - в направлении служебного порта (напр. :5001) на компьютере (тип 1)
После успешного соединения программа сообщает серверу ("тип 1"):
"в сети компьютер ХХХ , список доступных потров 80,25,110, активирован порт 80)
В ответ на это сервер поднимает сокет-листенер,
на котором отображает тот самый порт 80, например, на своем порту 6780.

Получается такой PCP-tunnel, только несколько иного типа:
по сокетам: [сервер_листенер]:80<-[клиент<->клиент]->:5001[сервер_листенер<->сервер_листенер]:6780)

Далее администратор подключается к компьютеру "тип 1" на служебный порт :5001,
получает список компьютеров онлайн, список доступных портов на них и
соответствие активных портов на клиенте, поднятым портам на сервере. (в нашем примере 6780->80)
Далее он (админ) может работать с этим портом, или дать команду
переподключить серверный порт 6780 на 25 порт клиента илди любой другой.

Вопрос:
Все это нужно писать с "0" или есть готовые системыс таким функционалом ?
Я даже не знаю по каким ключевым словам можно погуглиь :)

(Отдаленно все это напоминает TeamViewer.
Но с ним проблема - нет никакого доверия стороннему серверу "где-то там в Германии"
и функционал все-же не совсем под это заточен. )

Опечатка: правильно читать
TCP/IP-Tunnel
(на клиентских сокетах)

О VPN - "слышал где-то что-то".
Спасибо, попробую изучить эту тему получше.

Так, поскольку компьютеры (тип 2) в любой момент могут оказаться за HTTP прокси,
то для поднятия VPN придется использовать метод Connect.

Из этого следуют 2 вывода:
1 - сервер VPN должен висеть на 443 порту (т.к. на большинстве прокси только он разрешен для Connect)
2 - на всех компьютерах (тип 2) должна находится утилита, которая анализирует текущий способ подключения
и поднимает, при необходимости, туннель через прокси сервер. [todo: найти такую программу]

Сейчас нашел вот что: VPN через прокси
там упоминается какая-то утилита revinetd
[ ts уходит изучать]

Удивительно, как точно мне удалось описать в вопросе принцип работы revinetd .
За исключением, только, консоли администратора со списком компьютеров и портов.

Но почему-то revinetd не обновлялся с 2008 года.
Это наводит на мысли, что возможно, появилась какая-то замещающая технология.

Поскольку теперь у меня есть ключевые слова для поиска:
"reverse port forwarding, also known as a reverse port tunneling",
я стал изучать вопрос дальше и нашел какую-то libssh
у которой в описнии возможностей заявлен функционал
Reverse port forwarding
Еще не изучил какого года эта разработка, не заброшена-ли. И что вообще она может.
Расследование продолжается...