rPman

Интернет должен быть ethernet типа а не точка-точка (tap в идеологии linux, а не tun), а так же, ip удаленной машины vpn должен быть из твоей же локальной сети (обычно vpn делают отдельную локальную сеть, добавляя в нее машину клиента и удаленную машину, нужно найти или сделать самому правильный).

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

Мало того, в такой конфигурации можно прописать на локальных машинах таблицы маршрутизации (route add ... ) на выбранные подсети, что бы они ходили через локальный шлюз (который подключен к твоему провайдеру и через который у тебя работает интернет), список российских сетей можно взять тут (заодно осознаете, на сколько ущербным получается результат, к которому стремится наше правительство, бездумно копируя китайский опыт)

p.s. для работы из браузера есть лучше способ - прокси сервера, локальный socks прокси поднимается простым ssh -D1080 ... до любой vps-ки (ничего настраивать не нужно), а значит можно играть с профилями браузера и расширениями типа foxyproxy (осторожно со штатной .pac конфигурацией, при наличии ошибок в них браузеры без ошибок молча переключаются на direct подключение)

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

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

p.s. Но скорее всего причина все же в операторе, который блокирует какой-либо вид трафика, необходимый для работы whatsup. И формально, провайдер не просто не будет решать проблему, а будет готов это не делать по причинам того что компания meta 'запрещена' в россии и предоставлять услуги в т.ч. помогать ей он не обязан... такой вот у нас новый дивный мир

p.p.s. я могу ошибаться, но может проблема не в работе whatsup (т.е. оно работает, можно звонить и получать сообщения) а именно в получении уведомления и звонка, я серьезно не изучал вопрос но кажется 'при неправильной' настройке смартфона принимать звонки с заблокированным экраном он не умеет

Сайты могут детектировать виртуальную машину через gpu, а точнее ее отсутствие. Так же в виртуальных машинах может не работать DRM (защита видео контента от кражи), что тоже сигнал.

я правильно понимаю, что проблема только с яндекс.диск и только если качаете на hdd? если копирование с соседнего диска или на ssd нормально то это исключает проблему с сетью и проблему с диском.

Осталась проблема с софтом, которую решить смогут в яндекс, попробуйте им пожаловаться.

p.s. проблема с медленным hdd может возникать при многопоточной записи, а именно, hdd быстро (100мбайт/с) работает только в одном режиме - последовательная запись или чтение, а вот случайная работа с данными, роняет скорость примерно в сотню раз (в вашем случае 4мб/с вполне близко прогнозу) и это 'фича' технологии hdd, ведь для доступа к не последовательным данным, необходимо механически двигать считывающую головку и дождаться, когда диск повернется нужной стороной...

Это прекрасно было видно, при использовании torrent (у них в основе технологии - одновременная загрзка случайных частей файла), больше 10мбайт/сек сложно было получить (на windows, а вот на linux я отчетливо помню что торенты на hdd грузились заметно быстрее)...

но зачем яндекс диск использует многопоточную запись (это предположение а не утверждение) мне непонятно, но может там на этот момент есть настройки?

вариант в лоб - плохо обжат кабель, при использовании 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, т.е. без интерфейса ОС и возможности выйти за границы этого приложения. Сломать или как то проанализировать приложение в этом случае невозможно, а автоматизация для кражи данных решается лимитами доступа к ним.

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

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