>провайдер-гад очень не любит когда много людей сидит на одном логине
обычно это запрещено в договоре на оказание услуг, если я правильно понимаю, о чем идет речь

Еще иногда было так, что выдавали кому-то еще временно в инете полазить, то был целый гемор по его добавлению в конфиги squid, проверки по IP. Сейчас ему достаточно вообще с любой точки сети выполнить ssh -D и сразу получить инет. Или же подобный трюк с putty

Именно ) Но гад, потому что практически нелегально монополизировал сеть университета, и потому делает такие дурацкие правила. Других провайдером не пускают, так как свои все держат. Если он напишет что все пользователи интернета должны сидеть в розовых шапках и кроличьих ушах во время пользования, то мы это тоже дружно подпишем и будем выполнять, выхода нет. В IT-универе без инета просто сессию не сдашь. Мануалы на флешках носить?

Вопрос как эффективно использовать купленный траффик у этих козлов и правильно его распределять

> Соответствено сидим. Как бы вы это делали? Squid? ssh-тунель?

Зачем туннель в данном случае непонятно. NAT не подойдет?

Может еще есть решения получше так чтобы совсем вообщем-то не видно было провайдеру?

Может быть: роутер с nat-ом (вроде имеет смысл менять TTL в mangle POSTROUTING) и transparent-proxy (через squid, дабы UA-менять). Возможно, как-нибудь еще могут определить.

> Зачем туннель в данном случае непонятно. NAT не подойдет?

Все, понял... что это не только локально).

Гоняться они не будут сильно, просто очевидных вещей не надо типо открытого HTTP прокси. А зачем менять UA? Я что, в разных браузерах сидеть не могу.

NAT вообще можно. Какие там подводные камни? Просто я не сетевик вообще, потому не могу судить есть ли там такие же epic фейлы как открытый прокси порт

> зачем менять UA? Я что, в разных браузерах сидеть не могу.

Теоретически можно отследить разные OS. Может навести на подозрение.

http://ru.wikipedia.org/wiki/NAT

>> Теоретически можно отследить разные OS.
И браузеры с кучей разных минорных версий.

Это да, есть Gentoo, Ubuntu, Windows XP, Windows 7

> NAT вообще можно. Какие там подводные камни?

Не везде подойдет, неудобно управлять и на клиентах нужно gateway прописывать. Просто сначала подумалось, что клиенты в одном месте.

Вероятно, кошернее сразу openVPN поднимать.

Может я еще не до конца понимаю как оно будет работать, но как там с Vpn over vpn, vpn over wifi. Кажется с этим были проблемы у network manager и т.д

Нет, проверил. Есть VPN через WiFi

> как там с Vpn over vpn, vpn over wifi. Кажется с этим были проблемы у network manager и т.д

На сервере подключаемся к провайдерскому vpn, создается интерфейс ppp0. Забываем про провайдерский vpn.

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

Кажется с этим были проблемы у network manager и т.д

Это другое: была проблема подключится к vpn, из этой vpn к другой vpn. В нашем случае подключение к провайдеру осуществляется на сервере, клиенту о нем знать не нужно.

Я эже это понял, это я просто помню как не было возможности через WiFi подключаться к vpn.

А вообще чем это решение лучше? Ведь наверное трекать такой сервис проще простого. А в ssh зашифрованный трафик назначение которого не обязательно ясно. Хотя догадаться не сложно, но все де. Vpn тоже можно шифровать, но назначение понятно каждому и оно только одно, тырить у свой же, купленный инет ))

Не понял о чём вы говорите. Что значит на одном логине и какое дело провайдеру до того сколько у вас клиентов висит, до хоть 10.0.0.0/16

http://www.xakep.ru/magazine/xa/111/150/1.asp

хотеть странного

Еще вопрос. В рамках WiFi ни к чему шифровать трафик. Сейчас вкуриваю маны можно ли отключить ssh шифрование для всего этого громадного трафика и пользоваться им только на этапе логина. Это не секурно, но в данном случае годится

> А вообще чем это решение лучше? Ведь наверное трекать такой сервис проще простого.

Его ведь можно посадить на 443 порт. Прикрыть от нежелательных сетей.

А вообще чем это решение лучше?

Немного более универсально. И клиентский оффтопик проще подключать.

вот здесь немного есть: https://secure.dd-wrt.com/phpBB2/viewtopic.php?p=470143&sid=38420bb85551b97d7...

Разумеется, если решение с ssh-tunneling устраивает, лучше оставить. Можно ttl унифицировать.

И задать на тематических форумах вопрос от лица «админа провайдера»: как определить несколько систем за одной учетной записью).

>на клиентах нужно gateway прописывать

dhcp для кого придумали?

> dhcp для кого придумали?

Я так понял, что это не обязательно локально. То есть вполне может и провайдерский `dhcp' откликнуться. Придется править.

На WiFi - dhcp. Если из внешней сети, то тогда нет

> неудобно управлять

и что же там такого неудобного то?

и на клиентах нужно gateway прописывать

а DHCP для кого придумали?

Покупается один логин. И на нем должен быть один или два человека. Захардкодили они один или два. Для того что если человек сидит вконтактике, то заявленные 2МБ он никак не выюзает. Разве что качать. А вот если посадить человек 10 на это логин и они для его оплаты совсем копейками скинутся, то все 2Мб будут выюзаны 24 часа в сутки 7 дней в неделю. Это не профит для провайдера, он хочет чтобы каждый из 10 купил отдельный логин и юзал его на 10%.

А поскольку его все люту бешено ненавидят, то так ему и надо. Монополия - это плохо.

> и что же там такого неудобного то?

Ладно «иногда слишком низкоуровнево» - так сойдет?

а DHCP для кого придумали? - чуть выше.

Вот сейчас сижу на ssh, раздаю торрент. Периодически скорость всего траффика падает в 0 и так держится минуту, потом все ок. Это касается и торрентов и HTTP

И `dhcp' обычно провайдер (в подконтрольной ему локалке) тоже запрещает (и правильно делает).

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

Экономия бабла - первична.

в моей домашней локалке все работает так:
- NAT
- DNS
- маршруты и DNS раздаются по DHCP
- авторизация клиентов по WPA2 + mac-фильтр (+ выдача IP четко на основе mac) + сокрытие ТД.

DCHP светит только внутрь.
на WAN подцеплен провод от провайдера с pppoe туннелем.
со всем этим вполне справляется аппаратный роутер с dd-wrt внутри.

Сейчас еще думаю как соорудить гостевого юзера, который не смог бы ничего делать на сервере, кроме как использовать этого юзера для инета по ssh, возможно с форвардами

>В IT-универе без инета просто сессию не сдашь

Так это они вас так стимулируют на хитрости с ssh и прочими vpnнами, я раскрыл заговор.

Ну у нас там еще интстанс Oracle, достаточно активный в постоянном режиме deluged, Mysql, samba, apache, proftpd, VirtualBox с иногда запускаемыми виндами.

Аналогично вплоть до dd-wrt (только без mac-а, был, слетала прошивка... потом ставил по-быстрому).

Но ведь в сабже промелькнула необходимость разрешить доступ по ip, например кому-нибудь из другого корпуса, а не только из внутренней сети.

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

Вот бы соорудить его(аккаунт) так, чтобы он не мог лазить по серваку, только по инету.

Посмотри в сторону:

Match Group <restricted>
	ForceCommand /bin/false

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

Спасибо, посмотрю

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

в общаге

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


емнип, WPA2 позволяет авторизацию по radius делать.

>> неудобно управлять и на клиентах нужно gateway прописывать
DHCP.

>> Зачем туннель в данном случае непонятно. NAT не подойдет?

Все, понял... что это не только локально).

Локально, не локально. Какая разница? NAT в любом случае будет (если конечно прокси не использовать).

По сабжу имхо удобнее vpn-сервер поднять.
Насчёт ssh - сделать один логин для всех, но раздать каждому разный ключ (аутентификацию по паролю придётся для них вырубить). Далее можно в зависимости от ключа выполнять разные команды. (присвоить разные ip или ещё как-нибудь разграничить юзеров).

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

и говорите, что под тем же логином ваша жена и сын сидят.

Какое свинячье дело провайдеру знать, кто пользуется предоставленным доступом в сеть, если доступ осуществляется исключительно в пределах квартиры того, кто заключил договор, а не откуда-то извне?

у меня тоже не любит, но беспроводной роутер решает почему-то

> Локально, не локально. Какая разница?

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

КПИ-Телеком, да? Сочувствую. Они в последние годы совсем обнаглели.

По сабжу: OpenVPN + Squid с принудительной подменой UA. Доказать что-либо будет очень сложно.

Вот и я о том же. А поскольку «в пределах или нет» он определить не может, то и вообще не его дело.

> А поскольку «в пределах или нет» он определить не может...

... то начинает действовать презумпция виновности и считаться что сидят не только жители квартиры.

Начал читать, смотрю — знакомая ситуация. Посмотрел айпи — понял, о каком ты провайдере =). Я на нём же сижу. Хорошо, что опять снизили цены пару дней назад.

По сабжу: подключение на прова по pptp, раздача инета клиентам посредством openvpn. Такая конфигурация успешно опробована в боевых условиях.