Здравствуйте, Уважаемые Форумчане!

Имеется сервер в интернете, с 1 сетевым интерфейсом, на котором поднят почтовый сервер. Порты IMAP и POP3 доступны только с определенных IP.
Потребовалось дать доступ к просмотру почты пользователям с мобильных устройств, к сожалению открыть доступ к IMAP\POP3 для всех не представляется возможным, поэтому было принято решение установить на этом же сервере OpenVPN, с NAT'ом всего проходящего трафика.

Информация о конфигурации:
Публичный IP адрес сервера: 11.11.11.11;
Виртуальная сеть OpenVPN: 10.20.30.0/24;
Dovecot поднят на всех интерфейсах.

Одна из основных идей заключалась в том, что пользователи из доверенных сетей подключаются с помощь почтовых клиентов с использованием DNS имени, например smtp.domain.ru (реальный домен), для того, что бы при подключении к OVPN не менять настройки почтовой программы на 10.20.30.1 был поднят DNS сервер (BIND) с такой же зоной domain.ru, где smtp.domain.ru резолвится в 10.20.30.1.

named.conf: pastebin.com/MXtm3abK
ovpn.conf: pastebin.com/PKb9ZNxg
iptables: pastebin.com/V4EDEYh6

Теперь проблема: столкнулся с ней на Windows 7, с использованием OpenVPN GUI, при попытке пинга адреса по DNS имени smtp.domain.ru адрес резовлится не в 10.20.30.1, а в 11.11.11.11. При этом, если набрать nslookup, то все будет отлично, резолв происходит и прямой, и обратной зоны, с сервера, который выдался OpenVPN по DHCP, т.е. 10.20.30.1.

ipconfig /flushdns не помогает

Рассмотрение трафика на клиенте с WireShark показало, что DNS запросы в проблемное время идут не на 10.20.30.1, а на шлюз локальной сети клиента - 192.168.0.1.

Почему так? ЧЯДНТ?

route на клиенте: pastebin.com/yPPtkjeJ
ipconfig на клиенте: pastebin.com/ZDkK2BPg

Имеется сервер OpenVPN сервер с 1 сетевым интерфейсом (смотрит в интернет) с адресом: 11.11.11.11 Внутренняя виртуальная сеть OpenVPN: 10.20.30.0/24

На оборудовании так же стоит IMAP сервер

Правилами IPTables разрешен доступ к IMAP только с адреса 22.22.22.22 и с виртуальной сети - 10.20.30.0/24

  
# IMAP
iptables -A INPUT -i eth0 -s 22.22.22.22 -p TCP -m multiport --dport 143,993 -j ACCEPT
iptables -A INPUT -i tun+ -s 10.20.30.0/24 -p TCP -m multiport --dport 143,993 -j ACCEPT

Трафик клиентов проходит через NAT

iptables -A FORWARD -i tun+ -s 10.20.30.0/24 -o eth0 -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.20.30.0/24 -o eth0 -j SNAT --to-source 11.11.11.11

Проблема с которой столкнулся: подключенные клиенты OpenVPN не могут обратиться к внешнему адресу: 11.11.11.11, данную проблему я исправил добавил в конфигурацию сервера следующую строку:

push "route 11.11.11.11"

на Windows и Linux добавился маршрут 11.11.11.11 255.255.255.255 IP_адрес_сервера_в_тоннеле и все отлично работает, за исключением Mac OS X, на котором вначале добавляется маршрут 11.11.11.11/32 шлюз_локальной_сети_клиента, потом (судя по логам) имеются попытки добавить 11.11.11.11 255.255.255.255 IP_адрес_сервера_в_тоннеле, но с ошибкой:

 route: writing to routing socket: File exists 

конфигурация OVPN сервера: http://pastebin.com/p6sMvvrP
конфигурация OVPN клиента: http://pastebin.com/0tsuYPvY
правила IPTables: http://pastebin.com/b5xrdFPY

Имею связку Exim + Dovecot.

На MTA настроена авторизация из БД с хранением пароля в md5. На MDA пытаюсь настроить авторизацию(виртуальных пользователей на основе таблицы используемой Exim'ом), что привело к следующим изменениям стандартного конфигурационного файла

10-auth.conf

disable_plaintext_auth = no
auth_default_realm = mydomain.ru
auth_mechanisms = plain login
!include auth-sql.conf.ext

auth-sql.conf.ext

passdb {
  driver = sql
  args = /etc/dovecot/dovecot-sql.conf.ext
}

userdb {
  driver = sql
  args = /etc/dovecot/dovecot-sql.conf.ext
}

dovecot-sql.conf.ext

connect = host=127.0.0.1 dbname=exim user=root password=passworddb
default_pass_scheme = PLAIN-MD5

password_query = SELECT username, password, CONCAT('/var/mail/', %n) as userdb_home, 104 AS userdb_uid, 106 AS userdb_gid FROM users WHERE username = '%n'
user_query = SELECT CONCAT('/var/mail/', %n) as home, 104 as uid, 106 as gid FROM users WHERE username = '%n'
iterate_query = SELECT username AS user FROM users

104/106: Debain-exim Структура таблицы users максимально простая: id, username varchar(32), password varchar(32)

Пытаюсь произвести тестирование (telnet) и авторизация проходит только у системных пользователей, те, которые указаны в БД приводят в ошибке доступа, где может быть ошибка?

Исходные данные: Debian7 samba 3.6.6 pbis 7.1.1203 AD: Windows Server 2008 r2

Произвел установку PBIS по: habrahabr.ru/post/174497

Все прошло гладко, разделение прав работает, шары доступны.

Произвел настройку:

/opt/pbis/bin/config AssumeDefaultDomain true
/opt/pbis/bin/config UserDomainPrefix "MYDOMAIN"

[global]
        security = ADS
        workgroup = MYDOMAIN
        realm = MYDOMAIN.LOCAL
        server string = File Server %h

        machine password timeout = 0
        map to guest = Bad User
        guest account = nobody

Проблема заключается в том, что при такой конфигурации локальные учетные записи компьютеров, которые не введены в домен не ассоциируются с их копиями в домене. Подключение происходит только при написании имени домена, т.е. формат: DOMAIN\username. На toster.ru (который сейчас недоступен) посоветовали использовать «map untrusted to domain = yes», проблема логина ушла, но только на Windows XP, так же эта опция противоречит «map to guest = Bad User», которая позволяет открывать публичные шары гостям (без ввода логина и пароля).

Возможно ли сконфигурировать самбу с режимом «security = ADS», так, что бы локальные учетные записи ассоциировались с доменными (т.е. сделать формат username, а не DOMAIN\username), а так же открыть доступ анонимным пользователям?

Имеется сеть построенная на механизме NAT, lan:192.168.1.1/24, wan:xx.yy.xx.yy.

Во внутренней сети по адресу 192.168.1.22 стоит apache2 (Debian), на шлюзе стоит проброс xx.yy.xx.yy:zzzz на 192.168.1.22:8080, прописывалось не мной, доступа к шлюзу у меня нет.

При попытке подключиться из локальной сети (192.168.1.62) я вижу index.html, при попытке подключиться из интернета (88.34.35.11) пустой экран.

Насколько мне известно (на основе man iptables), TCP соединение устанавливается за 3 шага, SYN_RECV - показывает, что пакет из интернета миновал шлюз и пришел на 192.168.1.22, но ответ на этот пакет веб сервер отправить не может, почему - мне не известно, хотел бы попросить помощи у сообщества. Понять вывод tcpdump я не смог :(

tcpdump: http://pastebin.com

ports.conf http://pastebin.com

apache2.conf http://pastebin.com

netstat -na |grep :8080

tcp        0      0 0.0.0.0:8080            0.0.0.0:*               LISTEN     
tcp        0      0 192.168.1.22:8080       88.34.35.11:57900     SYN_RECV   
tcp        0      0 192.168.1.22:8080       192.168.1.62:51876      ESTABLISHED
tcp        0      0 192.168.1.22:8080       192.168.1.62:51877      ESTABLISHED

iptables --lsit

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination