Sergey_osv Posted August 18, 2003 Вот почитал на сайте www.vpn-connect.ru Интересное решение по предоставлению доступа в Интернет по выделенке через VPN. Защита от подстановки IP адреса и многое другое. Вопрос: почему провайдеры Екатеринбурга не используют подобные решения, это от недопонимания? от жадности? или технические трудности? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Sergey25 Posted August 18, 2003 Мы подключены через указанную систему более 3 месецев, пользуемся. Провайдер УГТУ-УПИ. В принципе у меня и сервак www.dostavki.ru через VPN-CONNECT ходит. Так что юзают провайдеры такие системы. в УПИ например более 2000 пользователей к ней подключенно. Хотя имхо можно и самим такую сделать, ну а можно и купить проверенную. Толпой скинуться и забыть о проблемах с воровством трафика. Хотя большие провайдеры не шибко хотят таких систем. В неразберихе проще обманывать, все равно если деньги у вас скачали они их вам не вернут. а им прибыль 8-) Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Sergey_osv Posted August 19, 2003 Кстати вот тема появилась насчет защиты от подстановки IP и MAC там народ уже тоже юзает вовсю в домсетях так что VPN это рулез! Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Vetal Posted August 19, 2003 так что VPN это рулез! Да не спорю, рулез. Но существует одна МАЛЕНЬКАЯ проблемка: при прокачке трафика из других внутренних подсетей, этот трафик считается как интернет. Кто как это победил? Прописывать роуты у клиентов - не предлагать. Все должно быть прозрачно и просто у клиента. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Mif Posted August 19, 2003 правила добавить прим такие # ! /bin/bash iptables -N local iptables -N inet_in iptables -N inet_out loc_net=172.22.23.0/16 xnet1=172.16.0.0/16 xnet2=172.19.0.0/24 xnet3=172.21.0.0/16 xnet4=192.168.0.0/24 iptables -A FORWARD -s $xnet1 -d $xnet1 -j local iptables -A FORWARD -s $xnet1 -d $xnet2 -j local iptables -A FORWARD -s $xnet1 -d $xnet3 -j local iptables -A FORWARD -s $xnet1 -d $loc_net -j local iptables -A FORWARD -s $xnet1 -d $xnet4 -j local iptables -A FORWARD -s $xnet2 -d $xnet1 -j local iptables -A FORWARD -s $xnet2 -d $xnet2 -j local iptables -A FORWARD -s $xnet2 -d $xnet3 -j local iptables -A FORWARD -s $xnet2 -d $loc_net -j local iptables -A FORWARD -s $xnet2 -d $xnet4 -j local iptables -A FORWARD -s $xnet3 -d $xnet1 -j local iptables -A FORWARD -s $xnet3 -d $xnet2 -j local iptables -A FORWARD -s $xnet3 -d $xnet3 -j local iptables -A FORWARD -s $xnet3 -d $loc_net -j local iptables -A FORWARD -s $xnet3 -d $xnet4 -j local iptables -A FORWARD -s $loc_net -d $xnet1 -j local iptables -A FORWARD -s $loc_net -d $xnet2 -j local iptables -A FORWARD -s $loc_net -d $xnet3 -j local iptables -A FORWARD -s $loc_net -d $loc_net -j local iptables -A FORWARD -s $loc_net -d $xnet4 -j local iptables -A FORWARD -s $xnet4 -d $xnet1 -j local iptables -A FORWARD -s $xnet4 -d $xnet2 -j local iptables -A FORWARD -s $xnet4 -d $xnet3 -j local iptables -A FORWARD -s $xnet4 -d $loc_net -j local iptables -A FORWARD -s $xnet4 -d $xnet4 -j local iptables -A FORWARD -s $loc_net -d ! $xnet1 -j LOG --log-prefix "inet_out " --log-level info iptables -A FORWARD -s ! $xnet1 -d $loc_net -j LOG --log-prefix "inet_in " --log-level info iptables -A FORWARD -s $loc_net -d ! $xnet1 -j inet_out iptables -A FORWARD -s $loc_net -d ! $xnet2 -j inet_out iptables -A FORWARD -s $loc_net -d ! $xnet3 -j inet_out iptables -A FORWARD -s $loc_net -d ! $loc_net -j inet_out iptables -A FORWARD -s $loc_net -d ! $xnet4 -j inet_out iptables -A FORWARD -s ! $xnet1 -d $loc_net -j inet_in iptables -A FORWARD -s ! $xnet2 -d $loc_net -j inet_in iptables -A FORWARD -s ! $xnet3 -d $loc_net -j inet_in iptables -A FORWARD -s ! $loc_net -d $loc_net -j inet_in iptables -A FORWARD -s ! $xnet4 -d $loc_net -j inet_in iptables -A inet_in -d 172.22.23.2 -j ACCEPT iptables -A inet_in -d 172.22.23.11 -j ACCEPT iptables -A inet_in -d 172.22.23.12 -j ACCEPT iptables -A inet_in -d 172.22.23.13 -j ACCEPT iptables -A inet_in -d 172.22.23.14 -j ACCEPT iptables -A inet_in -d 172.22.23.15 -j ACCEPT iptables -A inet_in -d 172.22.23.16 -j ACCEPT iptables -A inet_in -d 172.22.23.17 -j ACCEPT iptables -A inet_in -d 172.22.23.18 -j ACCEPT iptables -A inet_in -d 172.22.23.19 -j ACCEPT iptables -A inet_in -d 172.22.23.20 -j ACCEPT iptables -A inet_in -d 172.22.23.21 -j ACCEPT iptables -A inet_in -d 172.22.23.22 -j ACCEPT iptables -A inet_in -d 172.22.23.23 -j ACCEPT iptables -A inet_in -d 172.22.23.24 -j ACCEPT iptables -A inet_in -d 172.22.23.25 -j ACCEPT iptables -A inet_in -d 172.22.23.26 -j ACCEPT iptables -A inet_in -d 172.22.23.27 -j ACCEPT iptables -A inet_in -d 172.22.23.28 -j ACCEPT iptables -A inet_in -d 172.22.23.29 -j ACCEPT iptables -A inet_in -d 172.22.23.30 -j ACCEPT iptables -A inet_in -d 172.22.23.31 -j ACCEPT iptables -A inet_in -d 172.22.23.32 -j ACCEPT iptables -A inet_in -d 172.22.23.33 -j ACCEPT iptables -A inet_out -s 172.22.23.2 -j ACCEPT iptables -A inet_out -s 172.22.23.11 -j ACCEPT iptables -A inet_out -s 172.22.23.12 -j ACCEPT iptables -A inet_out -s 172.22.23.13 -j ACCEPT iptables -A inet_out -s 172.22.23.14 -j ACCEPT iptables -A inet_out -s 172.22.23.15 -j ACCEPT iptables -A inet_out -s 172.22.23.16 -j ACCEPT iptables -A inet_out -s 172.22.23.17 -j ACCEPT iptables -A inet_out -s 172.22.23.18 -j ACCEPT iptables -A inet_out -s 172.22.23.19 -j ACCEPT iptables -A inet_out -s 172.22.23.20 -j ACCEPT iptables -A inet_out -s 172.22.23.21 -j ACCEPT iptables -A inet_out -s 172.22.23.22 -j ACCEPT iptables -A inet_out -s 172.22.23.23 -j ACCEPT iptables -A inet_out -s 172.22.23.24 -j ACCEPT iptables -A inet_out -s 172.22.23.25 -j ACCEPT iptables -A inet_out -s 172.22.23.26 -j ACCEPT iptables -A inet_out -s 172.22.23.27 -j ACCEPT iptables -A inet_out -s 172.22.23.28 -j ACCEPT iptables -A inet_out -s 172.22.23.29 -j ACCEPT iptables -A inet_out -s 172.22.23.30 -j ACCEPT iptables -A inet_out -s 172.22.23.31 -j ACCEPT iptables -A inet_out -s 172.22.23.32 -j ACCEPT iptables -A inet_out -s 172.22.23.33 -j ACCEPT i=11 al=33 while [ $i -le $al ] do iptables -A local -d 172.22.23.$i -j ACCEPT i=`expr $i + 1` done i=11 al=33 while [ $i -le $al ] do iptables -A local -s 172.22.23.$i -j ACCEPT i=`expr $i + 1` done вот и всё.. трафик потом выбирать соотвестве из inet_in или inet_out... правда это её как следует не тестилось но ща по логам глядел и всё прально сетевой трафик в них не лезет... хотя может я что и не учёл... Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Sergey_osv Posted August 22, 2003 На самом деле прописать роуты у клиентов прийдется особенно если есть промежуточные роутеры. Это факт, чтобы уменьшить трафик через шлюзовую VPN машину. И это правильно и это не сложно и по другому нельзя. пример который выше не катит так как после установки VPN соединения у клиента он становится маршрутом по умолчанию 0.0.0.0 -> IP_VPN_server. А локальный трафик шифровать нет смысла и по VPN его гонять нет смысла. А роуты прописать один раз и все. Тем паче в локалку можно добавить game ftp mail и прочие серваки имеющие внутренний фейковый адрес и можно в гаму играть и без VPN соединения. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
martini Posted August 24, 2003 ну так блин , поставте в ип-ап шоб гейты новые добавлялись при соединении... и будет вам щастие. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Grumbler Posted August 25, 2003 так что VPN это рулез! Да не спорю, рулез. Но существует одна МАЛЕНЬКАЯ проблемка: при прокачке трафика из других внутренних подсетей, этот трафик считается как интернет. Кто как это победил? Прописывать роуты у клиентов - не предлагать. Все должно быть прозрачно и просто у клиента. Это проблема только для криворучек: надо ведь догадаться, что НЕ нужно считать внутрисетевой трафик. А вот излишнюю нагрузку на VPN-сервер снять помогает маршрутизация у клиента. Причем нормальные люди используют DHCP и все настройки маршрутизации клиент получает от сервера вместе с адресом и маской. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Vetal Posted August 25, 2003 Скажи мне, пряморучка, как в DHCP прописать доп. роуты на другие сети, что-бы это заработало на стороне клиента??? ПиСи Трафик между прочим считается на радиусе .... Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
terapeut Posted September 1, 2003 Да, да!! Как-бы так роуты клиентам автоматически закидывать? =) Не домен же для них виндовый поднимать, в самом деле! ну так блин , поставте в ип-ап шоб гейты новые добавлялись при соединении... и будет вам щастие. И чего это значит -- можно чуть прозрачнее? Нет, всё понятно, но что конкретно?.. :) Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Mif Posted September 4, 2003 а нельяз взять 2 машины... одна роутер внутри сети(№1)... дургая випиэн(№2) и гейт в инет... у клиента пишем шлюз внутрений(№1).. на нем пишем роутинг что и куда должно.... клиент обращаясь к випин серверу который лежит в другой сети роутается на роутере и всё... на №2 считается инет трафик а локальный до него просто не доходит а если и дойдет(что врядле при нормальном роутинге) то он должен сбросится... Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
terapeut Posted September 4, 2003 а нельяз взять 2 машины... одна роутер внутри сети (1)... дургая випиэн (2) и гейт в инет... у клиента пишем шлюз внутрений (1).. на нем пишем роутинг что и куда должно....клиент обращаясь к випин серверу который лежит в другой сети роутается на роутере и всё... на (2) считается инет трафик а локальный до него просто не доходит а если и дойдет(что врядле при нормальном роутинге) то он должен сбросится... В том вся и проблема, что локальных подсетей может быть _много_ и тогда при попыте связаться с несвоей локальной подсетью -- пакетики сыплются по VPN'овскому роуту по-умолчаию. Да ещё так бывает, что машины из одной подсети между собой норовят по VPN вязаться, когда он у них включен - приходится это дело закрывать. Надо бы попробовать поиграцца с ICMP-redirect'ом на VPN-сервере.. Приписать, что мол для таких-то destinations - отвечать ICMP(5/0) и пожалте - извольте проследовать! Надеюсь хотромудрый виндовс это проглотит и правильно переварит. Правада это не подойдёт, если пользователи подключаются также через интернет с целью попасть в локалку, но думаю это довольно экзотический случай, более актуальный для бизнес-применений и можно будет как-то это дополнительно разрулить при необходимости, тем более, что там и денег по-определению больше :) Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Cableman Posted September 5, 2003 так что VPN это рулез! Да не спорю, рулез. Но существует одна МАЛЕНЬКАЯ проблемка: при прокачке трафика из других внутренних подсетей, этот трафик считается как интернет. Кто как это победил? Прописывать роуты у клиентов - не предлагать. Все должно быть прозрачно и просто у клиента. Это проблема только для криворучек: надо ведь догадаться, что НЕ нужно считать внутрисетевой трафик. А вот излишнюю нагрузку на VPN-сервер снять помогает маршрутизация у клиента. Причем нормальные люди используют DHCP и все настройки маршрутизации клиент получает от сервера вместе с адресом и маской. А как ты поступаешь с клиентом, поставившим вин сервер и поднявшим ВПН в локалку? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
