объясните мне на пальцах, пожалуйста #2
[и снова здравствуйте, дорогие так называемые “программисты”]
почему все VPN-клиенты под “виндоуз” (или не все? я имел дело с двумя и мне видится тенденция) при подключении тупо нейтрализуют все остальные маршруты в таблице маршрутизации?
вот у меня, к примеру, стоит Microsoft Loopback Adapter, для связи с бегущей на этом же компьютере виртуальной машиной. в таблице маршрутизации прописано следующее:
Network Destination Netmask Gateway Interface Metric 10.0.0.0 255.255.255.0 10.0.0.1 10.0.0.1 25
VPN-клиент нейтрализует этот маршрут вместе с остальными, натурально.
я вижу три направления объяснения данного феномена:
1. в силу своего не вполне уверенного владения тонкостями TCP/IP вообще и маршрутизации в частности, я не вижу вот такого и вот ещё такого способа использования подобного loopback-маршрута злыми хакирами для прорыва в драгоценную корпоративную сеть.
2. в силу своего не вполне уверенного и т.д. я не понимаю, что компьютерная программа в принципе не способна со стопроцентной вероятностью отличить loopback-маршрут от не-loopback-маршрута.
3. разработчики VPN-клиентов не заморачиваются моими эзотерическими нуждами и делают как им проще.
расскажите, а?
Я бы предположил, что комбинация 2. и 3.
У меня никогда не было такой проблемы, более того я использовал два разных VPN клиента одновременно (oh, joys of M&A) и они трогали только свои собственные роуты
а как же в таком раскладе обеспечивалась изоляция?
Изоляция чего от чего?
драгоценной корпоративной сети от прочего зловредного интернета.
А какая разница? Мой компьютер может оказаться зловредным вне зависимости от routing table
нееет, применять так называемую “логику” мы не договаривались! :)
Неее, не все. Сисковский клиент только добавляет свою строку не портя остальной таблицы. В принципе, можно написать скриптец, которы будет вызывать VPN клиента + корректно править routing table…
ага, как же.
“routing table changed - connection lost”.
Я, может, не понимаю чего, но зачем это нужно? 127.0.0.1 (и вообще любой адрес со 127 в верхнем байте) отменили внезапно?
А вообще это, проблема действительно есть, появляется если хочется дать немножко интернетов компу, подсоединяемому по последовательному порту, мне вроде бы как удавалось её решить частично через persistent routes (”route add /p bla bla bla”), но там какая-то Чорная Магея в натуре.
тут хитро: виртуальная машина-гость должна как-то общаться с машиной-хозяином. и тут есть несколько вариантов, но у всех есть свои интересные недостатки, и все кроме SLiRP (который работает всегда, слава Аллаху, но уж очень тормозит) требуют заведения на машине-хозяине специальной иллюзорной сетевой карточки и с ней неиллюзорных маршрутов (которые, всё же, мне кажется, могут быть тривиальным образом опознаны как безобидные — об чём я тут и плачу).
нет, логика типичного корпоротивного VPN-клиента — это как раз ни в коем случае никаким другим физическим девайсам, окромя собственно подсоединяющегося, никаких интернетов не давать. что не вполне удобно, но в своём смысле логично — твой девайс как бы оказывается за могучим корпоративным брандмауэром, и подключен как бы прямо к стенке в офисе, что в принципе позволено только разрешённым девайсам, принадлежащим корпорации или как минимум поднадзорным корпоративному IT.
насчёт VMWare - ведь можно настроить NATting на хосте, и тогда виртуальная машина автоматом получит тот-же доступ, что и материнская операционка (я сам vmware именно так пользую)
NAT — один из тех самых вариантов, да.
не поможет, потому что VMWare создаёт иллюзорный адаптер для каждой виртуальной машины.
Можно попробовать openvpn: под линуксом он никаких чужих routes не трогает, подозреваю сходное поведение и у виндовой сборки.
если бы я мог выбирать манеру подключения, разве же я бы плакал? :)