Re: как дать доступ к почте и bind только openvpn клиентам ?
Не ожидал столько ответов...
Если в кратце:
основная идея была - давать ip клиенту (что-бы то же Апач на лаптопе
увидеть или диск подмонтировать, не вспоминая на каком они порту), а не
шифроваться.
К слову, если в конфиге openvpn клиента закомментирвоать route-gateway
192.168..., то после коннекта он виден по мнешнему, а сам идет в сеть
напрямую.
Но в процессе настройки выяснилось, что без vpn не работает traceroute
(!), если интернет через мобильник, а с vpn - работает.
Поэтому, что бы больше сюрпризов небыло - включил впн для всего, после
чего заметил, что "на почту и днс" клиент идет через внешнюю сеть, так
что сложно ограничить доступ к этим сервисам "не для впн" и появилось
желание разобраться.
Второй важный момент - дать возможность клиентам обращаться к сервисам
по его внешнему ip, т.к. заставлять клиентов менять dns сервер, после
соглашения с agreement, не удобно.
Вариантов оставалось два:
1. заворачивать трафик на клиенте на тап, даже если он идет на сервер -
пробовал (конфиг в одном из предыдущех писем) маркировкой всех
пакетов, кроме порта впн и перенаправлением его на tap.
Но сервер не отечает. (видимо ждет с tap запрос от 192... ?).
On 16.05.2011 06:01, Михаил Миронов wrote:
"запросы могут приходить на внутренний IP, но от внешнего IP
адреса клиента (если я не ошибаюсь). Вроде с этим сейчас и проблема."
Так внешний ip клиент получает на сервере в *nat postroute. Если он
завернут в vpn, то скорее наоборот - дает src ip 192..., а сервер
наверно удивляется зачем такой клиент обращается на сервер не по
внутреннему.
Разобраться с этим вариантом было бы очень интересно, что бы просто
понять как все работает.
Что можно попробовать ?
(если я заворачиваю на клиенте все кроме впн (8080) по маркеру
-A OUTPUT -p tcp -j MARK --set-xmark 0x5/0xffffffff.
-A OUTPUT -p udp -m udp ! --dport 8080 -j MARK --set-xmark 0x5/0xffffffff
ip rule add from all fwmark 0x5 lookup 100
ip route add default via 192.168.206.5 dev tap5 table 100
то запрос на сервере виден, dtpdump-ом, а ответ - нет.
)
> Файрволом закрываем данные сервисы на коннект из внешнего мира (с
> внешней сетевой карты) и разрешаем на них коннект с любого IP.
> Собственно, в результате доступ будет только с openvpn
Вы предлагаете сделать сервисы не доступными по их внешнему ip или
интерфейсу ?
Если по ip сервиса - это не лучший вариант, т.к. внешние dns дают на
него ссылку.
А если по интерфейсу клиента - да, так и планировалось. Но вот не
отвечают сервисы пока...
On 16.05.2011 07:05, Alexander GQ Gerasiov wrote:
> На нерутованном андроиде и openvpn'а то нет =)
А на рутованном, какой посоветуете ?
И к слову, ни у кого sshfs на андроиде не заработал ?
2.
On 16.05.2011 07:33, Mikhail A Antonov wrote:
> Не нужен ему третий IP. Клиент получает "второй" IP не на свой
> интерфейс, а ты ему всего лишь порты пробрасываешь натом
Что бы не путаться в числительных - если у сервера будет 2 ip, то
проблема решится роутингом, скорее всего.
Подитожу:
Один ip уходит клиенту "по ТЗ". Но даже если у клиента не будет своего
внешнего ip, вопрос остается прежним: можно ли, с помощью правильного
роутинга, обращаться к сервисам сервера через впн, при условии что у
сервера один ip.
Вопрос этот скорее "на понимание" (т.к. если IPs много - не жалко одного
на openvpn server, а если нет - то и клиентам раздавать не нечего -
будут по портам прыгать, и vpn не нужен - порт через ssh пробрасывается).
А вот понять как можно настроить роутинг в изначально предложенном
варианте - полезно.
--
Sincerely,
Nicholas
Reply to: