rPman

вариант в лоб - плохо обжат кабель, при использовании 100мбит используются не все жилы, а для 1000мбит - все

вероятность, что один провайдер, предоставив два физических кабеля, обеспечит на них суммарную пропускную способность 2x, они дадут два кабеля, воткнутые в один коммутатор

Но подключить двух разных провайдеров (только удостовериться что один не является противоантимонопольной дочкой другого), почему нет... лет 10 назад или больше у меня так были 2 провайдера, один основной 100мбит и второй резервный 100мбит (по акции подключал, два года платил какие то смешные копейки, да еще и абонентку можно было отключить, т.е. понадобился - докинул десять рублей на счет, и пару суток резервный интернет работает.

Так вот, красиво удвоить пропускную способность при двух кабелях будет не просто... один из вариантов, я определял подсети второго провайдера, и настраивал route его сети через него (та еще задача, выяснить список этих сетей), так вот у меня получалось что torrent мог загружаться на 20мбайт/сек, но только если сиды были в обоих подсетях (я тогда еще экспериментировал с подсетями, не принадлежащими обоим провайдерам, одни направлял через одного, другие через другого)... но других протоколов, позволяющих так легко удвоить производительность нет

p.s. если приобрести vps-ку (максимально близкую к вам, например датацентр в вашем городе) и настроить пару подключений vpn до каждого (таким образом что бы разные подключения шли по разному физическому проводу, что может быть не тривиально но linux позволяет и не такое) а затем поверх этих двух виртуальных ethernet (им даже ip не нужно выдавать), важно что бы это были tap (а не tun) подключения, настроить bonding (еще это называют транк), где есть разные режимы, например пакеты отсылаются по обоим каналам, давая повышенную гарантию отзывчивости, т.е. уменьшая jitter пингов, или по очереди, увеличивая ширину канала (что наверное вам и надо)... стоимость итогового решения будет - эти два провайдера и vps-ка, скорость которой должна быть выше 100мбит в два раза

нужен роутер с поддержкой прокси (настоятельно рекомендую тип прокси socks) многие роутеры не самые копеечные, позволяют доустанавливать пакеты, ищите в настройках.

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

Правильная схема - настроить vpn до дома (т.е. роутер работает как vpn клиент куда то, и нужен еще локальный vpn в твою локальную сеть, из которой ты уже получаешь доступ к прокси.

С некоторыми шансами (обычно он доступен но ковыряться в командной строке придется, ну и с беспарольной аутентификацией будут проблемы), можно получить на роутер ssh доступ (на нем должен быть ssh сервер), в этом случае если подключиться к ssh с ключом -D1080 (1080 порт, в putty это называется динамический туннель) получишь socks прокси, ничего дополнительно настраивать не нужно, пока открыто подключение ssh, будет работать прокси. Это тоже обычно надежная схема, но скорее всего из коробки не будет работать, придется поковыряться.

Когда я пытаюсь открыть какую либо новую вкладку с сайтом она грузится примерно секунд 3-5 а потом сайт функционирует нормально и когда я его закрываю а потом открываю он грузится нормально.

скорее всего косяки с настройками dns (указан неправильный или точнее сбойный), при подключении к vpn, обычно автоматически настраивается уже его dns сервер, а затем возвращается назад.

Что бы удостовериться, нужно открыть консоль разработчика браузера (F12), зайти на вкладку Сеть и зайти на сайт который должен глючить, в списке подключений выбрать самое первое (или то что долго по времени грузится) и посмотреть внизу вкладку - тайминги, тот что самый долгий и покажет кто виновен

Возможно это особенность вашего провайдера, технически можно разные порты и протоколы слать по разному пути

В браузере прокси не настроена? потому что webrtc игнорирует настройки прокси и работает напрямую

К модему по вайфаю подключено 3 устройства

устройство, куда подключен модем, может глючить (слабые роутеры со сбойной прошивкой или аппаратными проблемами)... ноутбук может спамить роутер большим количеством пакетов (типовой пример - коряво настроенный торент клиент, сотни подключений кладут любой старый роутер), так же ноутбук может запрашивать по какому-нибудь протоколу (например upnp) что-нибудь, но роутер сбоит и подвисает на попытке обработать эту команду.

Каскадирование vpn должно защищать от деанонимизации.

Ваш компьютер -> vpn на вашем компьютере (ip1) -> vpn на роутере (ip2) -> интернет (ip3)

Итак, для ваших программ (в зависимости от типа vpn, а то обычные прокси стали называться vpn и путать людей) ваш ip адрес будет vpn ip1, ваш настоящий адрес ip3, знает провайдер vpn на роутере, но провайдер vpn ip1 на вашем компе будет видеть что вы подключились к провайдеру vpn ip2 и может спросить его, а вот с какого ip адреса подключался человек в такой то день такой то момент, подключавшийся с вот такого ip. И если они придерживаются глобализации (а это почти весь мир кроме совсем уж типа россии, южной кореи и китая) то они скажут, а скорее говорят на автомате.

И да, эту информацию сообщают скорее всего не vpn провайдеры, они простые потребители интернет, а провайдеры, к которому они подключены.

А еще есть тайминг атаки - ваш vpn запрос это синхронно сразу пакеты к вашему провайдеру, от него к vpn второму, а от того к vpn первому, размеры пакета меняются по определенному правилу (зависит от протокола vpn но их не много и все они на автомате распознаются спец. железками), прекрасно видно что вот эти пакеты - один потребитель... есть протоколы. которые этому мешают (типа сети i2p) но и там есть методики деанонимизации.

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

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

запускай веб сервер
php artisan serve --host=0.0.0.0
а подключайся по ip адресу компьютера, на котором стоит веб сервер

Так как роутеры дешевые домашние, если в них какого то функционала не предусмотрено, то красиво решить не получится.

Но, скорее всего просто будет для ручного переключения делать несколько шевелений на роутере и может быть на машинах... в очень похожей ситуации я подсмотрел, какие http запросы делает роутер, когда меняешь настройки, и повторил их в curl (скопировав его из консоли разработчика браузера), и настроив пару простеньких скриптов, которые переключал настройки роутера по моему выбору на основной и резервный (параллельно запускал команду повторного получения настроек dhcp на машине, так как на роутере нельзя было изменить его автообновления на меньше часа).

Так как роутеры у тебя получается в одной локальной сети, то по уму можно было бы настроить что бы основной интернет выводил машины в сети по одному ip адресу (настройка у клиентов - шлюз по умолчанию), а резервный по второму, соответственно на машинах достаточно было бы сменить шлюз по умолчанию, что бы они выходили по нужному (сейчас у меня так в локальной сети vpn настроен)

Существуют сетевые протоколы, которые с некоторой долей везения будут работать даже если ОБЕ стороны за NAT (т.е. и сервер и пользователь), основаны на UDP и для их работы обычно требуется третий сервер с ip адресом, но не для передачи данных, а только для соединения.

Наилучшим приложением, которое позволило бы работать с данными в нескольких местах с их синхронизацией по сети, даже при отсутствии выделенного ip адреса - это syncthing (opensource, работает везде, по до все платформы, от PC до android и iphone).

Под вашу задачу может и не подойдет, так как это инструмент синхронизации данных, которые все должны храниться на обоих сторонах... зато работает без каких либо телодвижений и настройки (ну может в северной кореи и будущей России потребует настройку своего STUN сервера, у syncthing он тоже opensource) и естественно не требует хранение этих данных где то в облаке.

Сетевые устройства типа link/ether могут быть объединены в bridge и полученное устройство так же будет типа link/ether и ему можно назначить ip адрес (собственно у него будет полноценный mac и он получит его автоматически), по факту сетевой мост это виртуальный неуправляемый коммутатор (свитч), которые могут быть подключены каскадно (только кольца не нужно делать).

Если у тебя есть какой-либо vpn, так же создающий link/ether (pppoe это тоже), то его можно добавить в сетевой мост и он так же будет работать как ожидается. Т.е. у тебя может быть сетевой мост на нескольких компьютерах в сети, каждый компьютер может поднять свой vpn ether, и добавить его в этот сетевой мост. в итоге все эти vpn сети будут объеденены в одну локальную сеть, без настроек маршуртизации и дополнительных шевелений.

p.s. могут быть нюансы с arp таблицами, например при создании сетевого туннеля типа ethernet с помощью ssh, и объединение его tap0 в сетевой мост с физическим устройством из локальной сети будет работать, но с задержкой (примерно в 20 секунд) с момента подключения, пока информация об удаленных устройствах сети доедет до локальной (по крайней мере я эту проблему понял именно так), по каким то причинам, передобавление устройства в мост эту таблицу у bridge в других компьютерах локальной сети сбрасывает

Есть две 'задачи', какая из них вам нужна, не понятно:
1. передача данных по сети
* что бы никто не подсмотрел
* что бы никто не мог скрытно подменить
это решается ssl шифрованием и удостоверяющими центрами (которым можешь быть ты сам), пример https протокол и инфраструктура вокруг
2. предоставление гарантий что алгоритм на устройстве пользователя не будет подменен на похожий/прикидывающийся настоящим
* что бы никто не мог украсть данные
* что бы никто не мог украсть алгоритмы
* что бы никто не мог навредить соседним устройствам
Эта сложнейшая не решена, но в частных случаях есть какие то решения, типа обфускации алгоритма и структур данных для удорожания их понимания и внесения изменений... т.е. вся защита будет строиться на экономической целесообразности процесса, если взлом будет дороже профита от него, этим заниматься не будут.
Отличный пример - вместо запуска кода на машине пользователя, его можно запустить на защищенной удаленной машине, к которой доступ только по определенным правилам, тупой пример - удаленное управление машиной, на которой запущено требуемое приложение в режиме kiosk-mode, т.е. без интерфейса ОС и возможности выйти за границы этого приложения. Сломать или как то проанализировать приложение в этом случае невозможно, а автоматизация для кражи данных решается лимитами доступа к ним.

Технически нет проблем определить тип устройства и подсовывать разный веб-сайт. Посмотрите внимательно на адрес изначальной ссылки и то что в результате получается на смартфоне и ПК. Например изначальная ссылка проводит анализ и делает перенаправление на другой сайт.

Так могут делать мошенники с целью обмана, на смартфоне легче обмануть, меньше возможностей проследить за фишингом, поэтому для смартфона может быть так что один сайт мошенника, а другой на ПК безобидный.

ВСЯ вина на производителях роутеров.

Уже давно есть, и многие провайдеры не блокируют, ip6v4, но даже в тех небольших роутерах, где вроде бы есть поддержка ipv6, сделана она там на от*бись.

ПРАВИЛЬНО чтобы функционал был продублирован, или хотя бы фаервол был уровня NAT (т.е. либо NAT что для ipv6 не нормально но реально либо доступ из вне в локальную сеть закрыт полностью, но возможность открывать доступ парой кликов мышкой к компьютерам и сервисам), а есть максимум один чекбоксик - включить, и вся локальная сеть пользователя становится голой и доступной снаружи.

Что то вы не то делаете!

mixed content это сообщение в браузере! это значит вы запрос к вашему секретному управлению телеграм ботом делаете из браузера пользователя, все запросы видны, их можно вызвать вручную, в т.ч. догадаться о формате запроса.
Нельзя с браузера отправлять http запросы, так как пользователи, работающие в ненадежных сетях (например публичные wifi без пароля или с известным паролем), могут получить подмену этих запросов (особенно опасно стартовую страницу или скрипты так подгружать) или просто их подсмотреть. Бот телеграм обычно должен вызываться только с серверов телеграмма, но никак не пользователями напрямую http запросами.

Ваш веб сервер должен отправлять запросы в бота телеграм со стороны бакэнда (перепроверив условия, права доступа пользователя и т.п.). Так вот со стороны бакэнда нет никаких ограничений типу запроса.

Подключитесь к соседям в доме (достаточно просто чтобы провод был между ним и вами) и вот у вас уже локалка... больше людей, больше возможностей.

Вы можете собраться в несколько человек, скинуться и приобрести подключение к интернету (например через мобильную сеть), разделив затраты по какому то правилу, по которому договоритесь. Когда в ходу еще был http протокол и основной трафик был - текст, можно было за счет кеширования и прокси заметно уменьшить затраты на этот трафик, но теперь этой возможности нет в принципе (есть некоторые соглашения по типу retracker для torrent в локальных сетях, но не больше).

Технические вопросы - на машине (или рядом), которая будет подключена к интернету, нужно будет настроить NAT (не обсуждаем варианты выдачи каждому клиенту ip адрес, это бессмысленно в вашем случае) и собственно все... обычно любой роутер это может.

p.s. Учтите, что предоставлять услуги выхода в интернет без лицензии (точнее разрешения от госсударства) - запрещено и вы можете понести наказание (штрафы от 1т.р. до 300т.р. и даже наказание лишение свободы до 6 месяцев, уточните текущее состояние законодательства)

p.p.s. Учтите, что тот, кто заключит договор подключения к интернету, будет нести ответственность за действия остальных (если использовать vps то определять правила и наказывать будут в той стране, где запущен этот vps).

Отчетливо помню что примерно два раза в год читаю на хабре статьи подобного вида (правда решение в них разные), вот пример, погугли другие:

https://habr.com/ru/articles/760256/

Суть проблемы: глючит Windows Auto-tuning.
Это технология, которая обеспечивает оптимальное использование буфера для передачи данных между устройствами в сетевом соединении.

Причина, по которой он «сломался» сказать не смогу, но скажу решение:
* Запускаем cmd.exe от имени Администратора
* Последовательно вводим команды:

netsh int tcp set global autotuninglevel=disabled
netsh int tcp set global autotuninglevel=normal

* Если после ввода каждой команды выводится «ОК.» тогда всё хорошо.
* Компьютер перезагружать не обязательно.
* Заходим в браузер(ы) и радуемся!

еще:
https://habr.com/ru/articles/832100/

Есть лайфхак, который не всегда работает, особенно с мобильными пользователями (потому что ipv4 у опсосов закнчились а ipv6 поднимать у них кишка тонка, вот и пихают всех за двойной nat, из-за которого нормальные технологии не работают) - использовать webtorrent и webtorrent stream, на основе webrtc (передача контента напрямую между пользователями).

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

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

p.s. пример реализации хостинга - peertube