итд.
Лайк, шер, репост SSL слишком сложно для меня, а без этого, наверное, никак, да? остальное будет уже не удобно.
Было у заказчика желание и до абонентов злых провайдеров добраться, и домены не светить. А у меня давно идейка была в связи с помешательством на блокировках. Я прочитал, что proxy.pac может резолвить айпишки (isResolvable + dnsResolve), и пришла мне в голову мысль, что так ведь можно в DNS хранить команды, а в proxy.pac — читать их и интерпретировать. О том, может ли такое вообще работать, представления были туманные, а тут выдался шанс подтвердить гипотезу. Отзеркалил таблицу перенаправлений DNS в зону поддомена и заставил proxy.pac дописывать к хостам суффикс (этот поддомен) и пытаться резолвить то, что получилось, и в зависимости от этого ходить напрямую или через прокси. В общем и целом получилось так же, как и через SmartDNS, каждый шарит лучом в темноте и видит только нужный ему фрагмент, не видя всей полноты. Отличие — в том, что между клиентом и нашим сервером ещё появились DNS провайдера, а так работает очень похоже.
Один мой клиент раньше делал запросы к чужим сайтам с айпишки пользователя средствами Java, но ему не нравилось, как оно у людей тормозило. Я ему на Ada Web Server сделал JSONP-прокси на локалхосте, залоченный на его сайт, с установщиком для Windows, и чтоб сворачивалось в значок. Он через этот прокси получал валидный для айпишки посетителя прямой URL файлов на всяких OpenLoad и показывал их на своём сайте в HTML5 плеере.
Другой мой клиент промышляет тем, что хостит SmartDNS+прокси для обхода геоблокировок британских ТВ-сервисов. В собственно прокси тут особо много интеллекта не нужно, sniproxy справляется, но нужно отсекать халявщиков и как можно меньше раздражать плательщиков. Соответственно, если обнаруживается на первый взгляд левый запрос, его нужно кинуть в личный кабинет, а если там по кукисам вдруг резко стало понятно, что он свой, просто ему провайдер IP поменял, то нужно оперативно обновить IP и бросить обратно. Тут я на netfilter+ipset сделал такую систему, которая хороших бросает на sniproxy, а плохих — на веб-сервер, который отпинывает в личный кабинет, ну а попутно принимает запросы на синхронизацию из этого кабинета. При синхронизации нужно добавить и/или убрать IP из ipset, а чтоб пользователь не ждал две минуты, удалить объект conntrack. Это две разных сишных библиотеки. И личный кабинет написать надо было, чтоб запросы и на сервер, и в базу корректные делал. Получилось хорошо. У кого IP меняется, действительно оперативно туда-сюда бросает.
nginx location:
...
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
...
yesod config/settings.yml:
ip-from-header: "_env:IP_FROM_HEADER:true"
Чтобы не терялось.
а когда не блочили еще — работало
И у этого плагина есть замечательная фича, называемая Online Rule List — когда список паттернов подтягивается с сервера с указанной периодичностью.
Вопрос очевиден — а не запилил ли кто этот самый rule list в синтаксисе этого плагина на базе списков Роскомнадзора? Чтобы всё автоматически работало.
Интересуют способы, как заставить работать rdp подключение. Дома оно на 3389.
Заранее спасибо за помощь :3
Т.е. интернет доступен через некий локальный прокси, могу ли я послать трафик по такой схеме: комп->локальный прокси->прокси в интернете->целевой сайт ? И как это сделать, при условии, что у меня не доступа к локальному прокси?
[ng358ex@arch:~/proxy]$ ls -lh
итого 216K
-rw-r--r-- 1 ng358ex ng358ex 161K май 17 10:48 9148015_2.jpg
-rw-r--r-- 1 ng358ex ng358ex 48K май 17 10:48 9148015.jpg
Народ! Кто-нибудь сталкивался с таким?
/etc/dansguardian/languages# service dansguardian restart
Restarting DansGuardian: dansguardianerror reading: /etc/dansguardian/languages/russian_1251/fancydmtemplate.html
Download manager plugin init returned error value: -1
Error loading DM plugins
Error parsing the dansguardian.conf file or other DansGuardian configuration files
failed!
Что-то гугл не помог.
Если кто вообще знает о нём, то могу тогда выложить и конфиги
Всякие расширения вроде Proxy Switchy! не работают.
И объясните, почему оно всё так через жопу делается?
А рождаются они когда люди переносят роутинг Интернета со своего основного сервера на отдельную коробочку, видящую основной сервер со стороны его "доверенного" интерфейса, настраивают там проброс портов:
HTTP TCP From any host in wan To any router IP at port 80 > Forward to IP 192.168.0.100, port 80 in lan
...но на основном сервере при этом забывают убрать настроенный для внутренних хостов TPROXY ( version6.ru ):
for IF in $IF_TRUSTED; do
iptables -t nat -I PREROUTING -i $IF -p tcp --dport 80 -j REDIRECT --to-port 3128
done
В результате все входящие запросы на http:// внешнийайпишник / идут не на публичный ligttpd как должны, а заворачиваются прямиком на Squid для внутреннего пользования. Сканеры открытых прокси тут же сей факт обнаруживают, публикуют айпишник и порт на страницах типа soft-addict.blogspot.com
И за два дня пока всё это не было замечено, получаем во-первых бан в гугле ("Our systems have detected unusual traffic from your computer network. This page checks to see if it's really you sending the requests, and not a robot."), во-вторых более гигабайта логов в /var/log/squid3/
-rw-r----- 1 proxy proxy 244M 2012-06-25 12:50 access.log
-rw-r----- 1 proxy proxy 700M 2012-06-25 06:25 access.log.1
-rw-r----- 1 proxy proxy 227M 2012-06-24 06:25 access.log.2
Сейчас уже всё убрал, вдоволь на себя пофейспалмив и поorz'овав. Пожалуй откажусь от HTTP вообще, как от небезопасного протокола :P, домашний сервер будет только с HTTPS.