res2001

При чем тут ip route?
У вас все работает, нет только пингов. Значит все настроено правильно и маршрутизация работает как надо.
Очевидно, пинги блокируются фаерволом. Откройте их и будет счастье.

Вы не правильно понимаете.
При таком использовании как сейчас у вас смысла в poll особого нет, а так же нет особого смысла использовать его в блокирующем режиме сокета, т.к. в этом режиме recv (send) не вернет управление пока не сделает свою работу или пока не возникнет ошибка или пока не придет сигнал.

Если вы не стремитесь сделать некоторый вариант асинхронной работы с сетью, то poll и неблокирующие сокеты можно вообще не использовать.
В блокирующем режиме poll может быть полезен тем, что он поддерживает timeout, что может быть полезно, например для проверки флага не пора ли завершить поток или что-то в этом роде. Но и в этом случае нет гарантии, что recv (send) выполнятся без блокировки и сразу вернут управление. Поэтому timeout будет работать только в вызове poll, но не recv (send).

poll вам возвращает признак есть ли в сокете данные для чтения (или готов ли он к записи). Если да - вызываете recv (send), если нет можно поделать что-то свое, потом снова вызвать poll.

Кроме того имейте ввиду, что recv может получить не полный буфер, и send отправить не весь буфер.

Всегда анализируйте возвращаемые значения системных функций, особенно когда дело касается ввода/вывода.

Обычное явление - на роутере в фаерволе закрыты пинги на WAN порт.
Можете открыть их, если нужно.

На вай фай роутере настройте dhcp, чтоб раздавал какой-то не используемый диапазон из вашей подсети.
Ну и стоит настроить раздачу одних и тех же адресов по МАСу, а то все равно не будете знать какой адрес присвоен камере.

Для передачи вы видимо используете TCP. В ТСР нет разделения на сообщения, все данные передаются в одном потоке в том порядке, в котором были отправлены. Т.е. вполне реальна ситуация, когда вы посылаете например 2 сообщения по 10 байт каждое, а читает 3 раза по 5, 10, 5 байт за раз. Таким образом разделять на сообщения вы должны на принимающей стороне самостоятельно.
РОСО тут не причем - эменно так работает протокол ТРС. Вместо TCP можете использовать UDP - тут будете принимать именно сообщениями. Но есть сложность с дефрагментацией - если размер сообщения больше MTU, то сообщение будет фрагментировано при передаче и не факт, что куски дойдут и соберуться. Ну и еще UDP не гарантирует доставку, т.е. сообщения могут теряться и ни получатель ни отправитель об этом не узнает.
Так же можно использовать протокол SCTP, он так же как UDP работает с сообщениями, но при этом гарантирует доставку. SCTP входит в стандартный стек TCP/IP. Есть ли его поддержка в POCO я не в курсе.

Можно, конечно, и на уровне локального фаервола отрубить все попытки подключиться, но обычно это делается с помощью предоставления прав пользователям на подключение.
В винде пользователь должен зарегистрироваться на удаленном компе, чтобы получить доступ к его ресурсам. Просто не давайте этому пользователю доступ и все. В никсах, думаю, примерно та же схема.

Часто даже 100 метров, положенные по стандарту, не дают широко распространенные десктопные адаптеры от реалтека и марвела. Туда же большая часть встроенных сетевых адаптеров.
Больше 100 метров держат интелы и броадкомы. Причем они должны быть с обеих сторон кабеля, желательно одинаковой модели. Но 350 даже они не потянут без дополнительного промежуточного оборудования.

Смит "UNIX. Разработка сетевых приложений"
Книга именно про программирование. Про настройку, маршрутизацию, фильтрацию и т.п. тут нет.
В книге все описано применительно к unix, но база везде одинакова.
Книга уже довольно стара, но, по моему, актуальна до сих пор.

Настройте шейпер для IPTV трафика.

Это устройство - базовая станция. И да требуется лицензия на частоту вещания, а вместе с ней и операторская.

Возможно вам поможет направленная антенна + репитер. Но вопрос с правомерностью использования частотного диапазона они не снимут.

Попробуйте об организации связи там где вам нужно поговорить с местными операторами.

Не стоит разворачивать NAT - так вы зарежете другие возможности, например доступ к сетевым шарам в соседней сети станет не тривиальной задачей.
Виндовый фаервол относительно легко рулится удаленно даже без АД и т.п. - консольная команда netsh умеет удаленно управлять фаерволом. Естественно ее нужно запускать с админскими правами на удаленном ПК.
Надеюсь хоть логин/пароль админа у вас на компах один и тот же?

Несколько вариантов:
1.В текущей конфигурации вам нужно на вашем компе сделать шлюзом по умолчанию ваш ВПН сервер, тогда все пакеты для инета будут идти туда. Это можно сделать настройками ВПН на сервере.
Но в этом случае вы всегда в инет будете ходить через ВПН, а это, наверное не совсем то что вы хотите.

2.Если в эту схему добавить NAT на VPSе, то тогда приходящий трафик на веб сервер будет иметь ВПН адрес VPSа и ответы будут уходить VPSу без дополнительных телодвижений, затем ответы попадают в NAT и там выходят на ружу.

3.Перенести веб сервер на внешний хостинг.

Все ходят через фаервол.
Из логов видно, что приложение пытается подключиться по адресу 104.16.58.5 на порт 443 и у него это не получается - фаервол блокирует (другой вариант - сам сервер не доступен).

Не очень понятно где именно вы смотрите сетевую активность.

А что вас заставляет отключать сеть, когда подключаетесь к другой?
Адреса в сетях разные, друг с другом не конфликтуют, поэтому доступ будет одновременно к обоим в текущей конфигурации при одновременном подключении.
Нужно только чтоб оба сетевых адаптера были одновременно в компе.

Смотрите на то ПО которое будет крутится как на сервере так и на клиентах. Часто выбора нет совсем (например используемое ПО только под винду).
На сервере возможна виртуализация, т.к. на 15 компов у вас, возможно, достаточно не плохой сервер. Но это, конечно, зависит от нагрузки, которую будет тянуть сервер. В качестве гипервизора можете выбрать линукс+kvm|xen|.../ESXi/MS Hyper-V. В случае виртуализации лучше не совмещать на хосте роль гипервизора с чем-то еще - чем-то еще пусть занимаются виртуалки.

Если используемое ПО позволяет выбор ОС, тогда включайте другие критерии отбора: умения работать с ОС как админов так и юзеров (хотя юзера обычно с ОС не работают - они работают с приложениями), цена, и т.п.