а цель какая? на сегодняшний день такой возможности в винде нет. вопрос очень похож на изыскания на тему создания ботов (оч популярная тема). в принципе, на программном уровне это реализовать возможно, но придется довольно много что освоить.
есть еще варинт создавать виртуальные машины, а в каждой свой vpn и экземпляр бота
Нужна смена IP адреса. Вопрос скорее денежный, потому что прокси использовать дороже получается, если нужно много стран. Ну и искать прокси нужно еще, VPN в этом плане удобнее. Но у VPN есть недостаток в виде виртуального адаптера, что мне не очень подходит.
Виртуальные машины для такой цели тоже не очень удобны, потому что виртуальные у них не только сети, но и файловая система и прочее
ranftldieter, тогда вариантов не много:
- пробуйте решить под линукс, если там есть такая возможность
- создайте или закажите программное решение (бот, который сам поднимает впн для каждого экземпляра)
а перечислять недостатки других способов смысла нет
Решил с помощью виртуальных машин, но немного по другому. Создал виртуалку Debian, настроил на ней SOCKS сервер и OpenVPN. Как итог: хост подключается к виртуалке как к прокси, соответственно и программы отдельные выделить можно, но сервера используются из VPN
ranftldieter, но если сделали на одной виртуалке несколько впн и прокси для них - пишите свой ответ с понятным описанием. для других. это нормально. и правильно
ranftldieter, нуу.. кодеры, особенно веб-разрабы, которым почему то все равно нужна винда в головной системе, пищат от восторга уже (??) пару лет наверное ;))
на заметку - начиная с релиза 1910, появляется понятие WSL2. сам пока не погонял, но если верить промоушену, интеграция еще глубже. то есть возможен и дополнительный выигрыш в ресурсах
ranftldieter, и еще - в WSL юбунтах много нареканий как раз на сетевые фичи. сам пробовал поднимать ssh сервер, в юбунтах не взлетал, в дебиане как часы (речь о дистрибах wsl из магазина винды)
#, попробовал запустить Debian, он выдает что компонент WSL не активирован, хотя в настройках включен. Попытаюсь решить проблему, а там напишу если получится прокси поднять с VPN
с учетом сленговой перегрузки, о чем спор понять сложно, но Армянское Радио, если вы хотите предложить ТС использовать возможности виртуальных свичей, то не все так просто:
- ТС хочет разделение на уровне приложений, а не ВМ
- не припомню возможности создать виртуальный свич для не физического интерфейса, как то VPN, PPPoE, ADS и тд
- не припомню возможности создать виртуальный свич для не физического интерфейса, как то VPN, PPPoE, ADS и тд
Если качественно упарываться - можно разрулить и на виртуальных интерфейсах через общий доступ к vpn подключению. Но это изразряда очень тяжёлых наркотиков.
#, скрин чего? Я не буду на рабочих машинах городить огород ради вас. В Hyper-V есть три типа витуальных коммутаторов: внешний, с привязкой к физическому интерфейсу и с возможностью создания виртуального адаптера на хосте; внутренний - без привязки к физическому адаптеру, с созданием виртуального адаптера на хосте; и private - сугубо между виртуалками.
Да, сторонний виртуальный адаптер нельзя напрямую подключить к свичу Hyper-V, но можно смаршрутизировать туда трафик от виртуального интерфеса Hyper-V, грубо говоря. ICS - это упрощённый минимальный механизм маршрутизации.
#, я не очень понял что вы в итоге пытались сделать. Цель понял, процесс не понял. Если у вас кабель от провайдера приходил в физический интерфейс хоста - вам и надо было "пробрасывать" его в виртуалку без участия хоста. pppoe-соединение устанавливать уже на самой виртуалке-роутере. Бриджить физический интерфес с виртуальным тоже было можно было. А вот бриджить само pppoe-подключение уже нельзя. Винда и не дала бы, никсы не знаю.
Тут речь не о мосте. ICS как маршрутизатор с nat работает, на хосте. Чистый l3, другими словами. Т.е. выглядеть это должно так: [провадер]<->[физический интерфейс на хосте][[pppoe]<-[ICS(nat)]<-[виртуальный интрефейс гипервизора]]<->[vm].
Поэтому я и говорю, что это сделать можно, но не нужно - костыль на костыле и костылём погоняет; да и ICS довольно капризный; шаг влево, шаг вправо - расстрел на месте.
#, знач так, уважаемый, я всё понимаю, но особенно я понимаю то, что вы как раз не очень хорошо понимаете, о чём вы говорите.
Hyper-V Switch - это одна сущность. Осуществляет l2 коммутацию.
Мост, создаваемый средствами windows - это другая сущность. Тоже осуществляет l2 коммутацию.
ICS - реализация маршрутизатора с nat. Осуществлет l3 маршрутизацию. Он НЕ СОЗДАЁТ мостов. Ни в каком виде. Работает ТОЛЬКО на l3.
Hyper-V Switch может работать только с физическими интерфейсами хоста, может создавать виртуальные интерфейсы на хосте и в витуальных машинах. de-facto управляемый свич
Мост, создаваемый виндой, может прекраснейшим образом организоваваться как между физическими интерфейсами, так и между виртуальными интерфейсами, включая виртуальные интерфейсы гипервизора, но НЕ может создаваться с участием интерфейсов удалённого доступа, как, например, pppoe. de-facto неуправляемый свич
ICS может работать С ЛЮБЫМИ интерфейсами, но со всеми - одинаково через жопу. de-facto огрызок роутера
#,
>у тебя есть что полезного сказать для ТС?
По-моему очевидно, что я ни слова не говорил о проблеме тс.
>давай подскажу - рейтинговыми баллами ;)).. когда они подрастут
Это не позиция специалиста.
Ваш высокий рейтинг что-то не особо позволил вам увидеть разницу между тремя разными механизмами.
>какой ты нудный
Как будто в этом есть что-то плохое.
Раньше это делалось так:
- подключаемся к впн без использования маршрута по умолчанию (у нас появляется доп.сетевой интерфейс)
- в файрволле говорим каким программам на какой интерфейс долбиться
Делал такое на ESET
Средний
