Блог Ваганова Николая

приключилась история ставить openvpn
Нужно : поднять openvpn для анонимной работы в Internet
ставил из репо

переносите из /usr/share (В данном случае /usr/share/doc/openvpn)папку easy-rsa в /etc/openvpn

aptitude install openvpn
nano /etc/openvpn/easy-rsa/2.0/vars :

export KEY_COUNTRY=RU
export KEY_PROVINCE=MO
export KEY_CITY=MOSCOW
export KEY_ORG=Firends
export KEY_EMAIL= mymail@domain.org

можете править на свое усмотрение

cd /etc/openvpn/easy-rsa/2.0/
source ./vars
./clean-all
./build-ca
./build-key-server server
./build-dh

nano /etc/openvpn/server.conf

server.conf :

port 1194
proto udp
dev tun0
ca /etc/openvpn/easy-rsa/2.0/keys/ca.crt
cert /etc/openvpn/easy-rsa/2.0/keys/server.crt
key /etc/openvpn/easy-rsa/2.0/keys/server.key # This file should be kept secret
dh /etc/openvpn/easy-rsa/2.0/keys/dh1024.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
keepalive 10 120
comp-lzo
persist-key
persist-tun
status openvpn-status.log
verb 0
local <внешний IP сервера>
push «redirect-gateway»
tls-server
push «route 10.8.0.0 255.255.255.0»
user nobody
group nogroup

!!ВАЖНО!!
симпл конфиг находится по адресу /usr/share/openvpn/
можно скопировать его и просто менять данные
выкиньте лишний мусор типа описания функций. ИМХО при правке все разбредается и не сконцентрироваться.
по умолчанию стоит «group nobody». Поверьте, деба не поймет)) следует изменить на nogroup
для работы нужен tun/tap модуль так что и его нужно установить

Создаем конфиги для клиентов. Имена файлов соостветствуют Common Name
mkdir /etc/openvpn/ccd
nano client1 :

ifconfig-push 10.8.0.6 255.255.255.0

Создаем ключи для клиентов
cd /etc/openvpn/easy-rsa/2.0/
source ./vars
./build-key client1

Большинство параметров подхватятся из файла vars. Только параметр Common Name надо указать явно, и его значение должно быть таким же, как и параметр вызова скрипта build-key

Конфигурация клиента client.ovpn :

client
dev tun0
proto udp
port 1194
remote
tls-client
dh dh1024.pem
ca ca.crt
cert client1.crt
key client1.key
verb 3
comp-lzo
redirect-gateway def1
nobind
ns-cert-type server
resolv-retry infinite

устанавливаем себе openvpn-gui
заходим в папку config
создаем client.ovpn
копируем с сервера ключи dh1024.pem , ca.crt , client1.crt , client1.key в эту же папку.

правила которые будем добавлять в iptables на сервере :

echo 1 > /proc/sys/net/ipv4/ip_forward Включаем форвардинг

iptables -A INPUT -i tun+ -j ACCEPT
iptables -A FORWARD -i tun+ -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -j SNAT —to-source <внешний IP сервера>
iptables -A FORWARD -s 10.8.0.0/24 -j ACCEPT
iptables -A FORWARD -d 10.8.0.0/24 -j ACCEPT
iptables -A FORWARD -p tcp —tcp-flags SYN,RST SYN -j TCPMSS —clamp-mss-to-pmtu

Для Vista добаляем в конфиг клиента :

route-method exe
route-delay 2

и работаете)

вообщем то и все.=)

Передо мной поставилась задача поднять прокси socks5 сервер на Debian, причем сложность заключалась в поднятии сокса на 2 IP с авторизацией. На ум сразу пришел squid потому что только недавно его ставил, память свежая да и в конфигах подразобрался. Ан нет! Оказывается squid ни в какой форме не поддерживает socks, что я выяснил на офф сайте, хотя по уверению многих его нужно просто пересобрать. Стал искать и сначала остановился на Dante, однако мне подсказали что он скажем не очень хорошо отрабатывает и пришлось искать альтернативу. Самое интересное что при всем нынешнем разнообразии всякого рода стаффа нет приличных proxy-серверов с поддержкой socks5. Вспонил 3proxy которую так недавно сравнивал. Ну чтож 3proxy дак 3proxy.
Потопал на сайт и скачал свежую версию. После разархивирования начался процесс компиляции который через 4 часа пошел в rm -rf. Нормальных аналогов не нашел и решил все-таки добить его.
На одном сайте нашел старенькую версию и раскрутил ее.
1 — Разархивирование
тут все просто

tar -zxvf 3proxy-0.5.3j
cd 3proxy*

2 — Компиляция
Эта версия как и все остальные не обошлась без приколов с компилированием но установив все необходимое наконец то перестало выплевывать ерроры и осталась только пачка варнов на которую я решил забить. Компилировать будем Makefile.unix из флагов линковщика которого нужно удалить «-DNOODBC». итак

make -f Makefile.unix

3 — Настройка
Переходим в образовавшуюся папку src и любуемся на полученный продукт. Теперь нужно создать конфиг с расширением cfg

mk proxy.cfg

Далее начинается момент конфигурирования. У нашего нового прокси действует следующая схема :

—МЫ——>internal_interface=3proxy-server=external_interface<——WWW——

следуя логике нам нужно задать входящий, исходящий интерфейс, авторизацию и порт.
итак

nano proxy.cfg

##ОБЩИЕ НАСТРОЙКИ

#сразу бекграундим процесс
daemon
#убираем логи(хотя можете и оставить=) Все логи хранятся в txt формате
logs /dev/null

### юзеры. Флаг CL говорит о том что пароль лежит и будет браться нешифрованным
# за другими флагами топаем на офф сайт
users login1:CL:password1
users login2:CL:password2

## socks server

#задаем авторизацию по паролю
# за другими флагами топаем на офф сайт
auth strong

#задаем демон и порт
socks -p8989
#задаем входящий/исходящий интерфейс сервера
internal ip.ad.dr.es
external ip.ad.dr.es

#аналогично настраивается proxy server
#все в принципе сервер готов к эксплуатации

./3proxy proxy.conf — старт демона
killall 3proxy — остановка

Но нам нужно 2 внешних и два внутренних интерфейса. Вот тут то и вышла загвоздка.
У автора на сайте указана следующая комбинация :

allow login
parent 1000 http ip.ad.dr.es 0
allow login2
parent 1000 http ip.ad.dr.es 0

Но она у меня ни под каким видом и ни при каких настройках НЕ ЗАРАБОТАЛА
Думаем далее. Нужно 2 интерфейса? Будет 2 сервера. копируем 3proxy получается 3proxy1.
Второй хотя и запускается с измененными параметрами но работает криво и некрасиво и вообще никак. далее увидел вот такой вот тип запуска отдельных демонов из папки src :
./proxy -i -e -p
./socks -i -e -p

i — internal
e — external
p — port
но была сразу припечатка что такой метод не поддерживает никакой авторизации. И правда нужных флагов из ФАКА не нашлось. Далее я заметил, что все вписываемые параметры практически идентичны флагам запуска из строки и каково же было мое удивление когда сначала проверив вот такой вот метод как положено
./socks -iIP.AD.DR.ES -eIP.AD.DR.ES -p8989

а потом накатав по быстрому конфиг :

daemon
log /dev/null/
socks -iIP.AD.DR.ES -eIP.AD.DR.ES -p8989

все тоже заработало причем на обоих интерфейсах
Настало время прикручивать авторизацию. В вызове из строки у нас нет такого флага но в запуске с конфигом он есть так что набросав по быстрому вот такое :

users login:CL:password
daemon
auth strong

socks -iIP.AD.DR.ES -eIP.AD.DR.ES -p8989

в оба конфига все заработало.
ЗЫ На эту «базовую настройку» я потратил 4 дня (по 13 рабочих часов)

Решил на досуге сравнить 2 известных прокси сервера 3proxy и squid и выявить плюсы и минусы.

Итак плюсы 3proxy :

— во первых есть русскоязычный сайт (http://3proxy.ru) с самой что ни на есть полной документацией по программе
— есть англоязычная версия этой программы так что ее работоспособность проверена не только любителями халявы, но и остальными фракциями=)
— кроссплатформенность 3proxy (UNIX/LINUX , Windows 95/98/ME/NT/2000/XP)
— стоит отметить легковесность программы (нескомпилированный дистр 469кб)
— простота настройки (очень подробный фак)
— веб админка
— протоколирование ошибок делает настройку рабочего дистра легче

Минусы 3proxy :

— отсутствует в репо (проверял на Debian Lenny) Выдержка с офф сайта : «В настоящее время нет постоянного мэйнтейнера порта 3proxy для многих дистрибутивов.»
— поставляется для UNIX/Linux в исходниках (компиляция требует дополнительных навыков)
— все таки адаптация больше идет в сторону Win осей

Плюсы squid :

— за счет распространенности в интернете можно найти много статей с русской документацией
— о squid не знает лишь ленивый, что доказывает распространенность программы и многочисленные посты на форумах так же показывают, что используется этот сервер крайне плотно
— реализована кроссплатформенность под все используемые в работе системы
— для не Win систем качается из репо, что является плюсом (не требует компиляции)
— найдена веб админка http://stc.nixdev.org/ судя из демо, очень очень неплохая
— адаптировано под иксы, что мне очень нравится))
— протоколирование ошибок делает настройку рабочего дистра легче
— громоздкость конфига заменяет гибкость настроек

Минусы squid :

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

Итог :

Оба сервера поддерживают все распространенные методы проксирования и при должной конфигурации будут работать стабильно и отвечать поставленным требованиям (учет трафика, учет пользователей, анонимность). Стоит заметить, что squid более ориентирован на nix публику, чем 3proxy, соответственно более востребован в качестве прокси сервера на nix серверах, коих больше нежели остальных. Присутствие в репо делает squid более привлекательным, однако в простоте конфигурирования он уступает 3proxy. При поиске информации в интернете я определил сообщество, которое ставит squid в больших организациях и обширных локальных сетях(хотя они скорее MAN чем LAN), что доказывает, что squid внедряется больше чем 3proxy, для выполнения многогранных задач, требующих тонкой настройки, и больших ресурсов.

Личный итог : Более понравился squid, несмотря ни на что.

PS Оценка чисто субъективная и основана на личном опыте и поиску информации при подготовке статьи. Я не пытаюсь разводить холиваров между сисадминами nix и win а лишь высказываю собственное мнение)

Вот такая вот интересная задача встретилась. Порыв интернет не нашел однозначного решения и решил взять из всего по чуть-чуть, получилось лучше чем думал.
Пропущу главу с установкой squid'a так как на этом этапе не должно возникнуть никаких сложностей и сразу перейду к настройке. у меня получился вот такой блок для /etc/squid3/squid.conf :

auth_param basic program /usr/lib/squid3/ncsa_auth /etc/squid3/passwd
acl ncsa_users proxy_auth REQUIRED
http_access allow ncsa_users

#Задаем acl'ы для последующего использования

acl auth1 proxy_auth user1
acl auth2 proxy_auth user2
acl auth3 proxy_auth user3
acl auth4 proxy_auth user4
acl auth5 proxy_auth user5
acl auth6 proxy_auth user6
acl auth7 proxy_auth user7
acl auth8 proxy_auth user8
acl auth9 proxy_auth user9
acl auth10 proxy_auth user10
acl auth11 proxy_auth user11

#Задаем IP на которых будет слушатся сервер

http_port ip.ad.d.dr.es1:3128
http_port ip.ad.d.dr.es2:3128
http_port ip.ad.d.dr.es3:3128
http_port ip.ad.d.dr.es4:3128
http_port ip.ad.d.dr.es5:3128
http_port ip.ad.d.dr.es6:3128
http_port ip.ad.d.dr.es7:3128
http_port ip.ad.d.dr.es8:3128
http_port ip.ad.d.dr.es9:3128
http_port ip.ad.d.dr.es10:3128
http_port ip.ad.d.dr.es11:3128

#Задаем IP выхода для определенных пользователей

tcp_outgoing_address ip.ad.d.dr.es1 auth1
tcp_outgoing_address ip.ad.d.dr.es2 auth2
tcp_outgoing_address ip.ad.d.dr.es3 auth3
tcp_outgoing_address ip.ad.d.dr.es4 auth4
tcp_outgoing_address ip.ad.d.dr.es5 auth5
tcp_outgoing_address ip.ad.d.dr.es6 auth6
tcp_outgoing_address ip.ad.d.dr.es7 auth7
tcp_outgoing_address ip.ad.d.dr.es8 auth8
tcp_outgoing_address ip.ad.d.dr.es9 auth9
tcp_outgoing_address ip.ad.d.dr.es10 auth10
tcp_outgoing_address ip.ad.d.dr.es11 auth11

ip.ad.d.dr.esN — это внешние IP сервера
порт взял стандартный 3128

Самая фича в том, что не нужно менять IP прокси чтоб ввести нового пользователя, так как их распределение идет в процессе авторизации и привязывается именно к логин/пассу.