Есть VPN-сервер на Freebsd, используется демон mpd. Также есть Debian сервер.
Нужно подключаться к VPN, используя IP сервера с Debian, как будто VPN установлен на нем. Очевидно, нужно пробросить порт.
Делаю так (нашел где-то в сети):
iptables -t nat -A POSTROUTING -s <freebsd_ip> -o venet0 -j MASQUERADE
iptables -t nat -A PREROUTING -p tcp -d <debian_ip> --dport 1723 -j DNAT --to-destination <freebsd_ip>:1723
iptables -t filter -A FORWARD -i venet0 -d <freebsd_ip> -p tcp --dport 1723 -j ACCEPT
VPN при этом подсоединиться не может. Если меняю порт на 80, то видно ответ апача с freebsd-машины, то есть в каком-то виде проброс порта функционирует.
Что я сделал неправильно, и как сделать это правильно?
как его пробросить?
пробую так:
root@novo [~]# iptables -t nat -A PREROUTING -p gre -d 92.63.103.175 --dport 47 -j DNAT --to-destination 89.189.185.215:47
iptables v1.4.2: Unknown arg `(null)'
Try `iptables -h' or 'iptables --help' for more information.
есть ещё советы сделать так:
root@novo [~]# modprobe ip_nat_pptp
FATAL: Could not load /lib/modules/2.6.18-308.el5.028stab099.3PAE/modules.dep: No such file or directory
нашел вот такую инструкцию: greydog.mmm-tasty.ru/tag/iptables
сдела всё по ней, кроме modprobe, ибо он не работает с ошибкой указанной выше.
теперь vpn пытается подключиться дольше, проверят имя-пароль, но в итоге всё равно обламывается.
схема работы:
vpn-сервер в новосибирске
люди в тайланде
коннект тайланд-нск феерически хреновый
есть vpsка в москве.
коннект тайланд-мск и мск-нск хороший.
нужно чтобы люди цеплялись VPN на IP впски в москве, которая пробрасывала бы соединение до новосибирска.
да я б попробовал, но для меня это всё равно что попробовать собрать шатл на балконе и улететь на луну =)
нужно поставить VPN-сервер на Debian, завести там учетки пользователей и они будут к нему коннектиться? а дальше как их в нск переправить?
А дальше они будут коннектиться к адресу из локалки второго ВПН сервера.
т.е. они дошли по одной трубе до первого бункера, из которого пошли по второй трубе до места назначения.
Мне кажется по ресурсам это будет равнозначно варианту с пробросами/натом
эм… не понял. с точки зрения клиента это как выглядит? сказали соединиться с одним впн-сервером, ждем пока соединится, после чего говорим соединиться со вторым? а винда так умеет? она первое соединение не отключит, когда я ко второму захочу прицепиться?
если всё так, то насколько я понимаю, никакой настройки на обоих серверах не нужно делать, просто поставить VPN-сервер на Debian, и на клиентах создать два подключения вместо одного?
я это к тому спрашиваю, что не очень понятна ваша фраза «тогда останется только пошаманить с маршрутизацией»… вроде бы на мой дилетантсвкий взгляд шаманств не нужно?
А вторая ВПНка — клиента не колышит, сервера между собой сами договорятся.
С точки зрения клиента — запустили подключение и цепляются к целевому хосту.
А между серверами я бы поднял IPSEC.
Я не знаю реалий в вашей ситуации.
Но я бы решил так:
На стороне клиента — какой-нибудь дешевый маршрутизатор, который держит ВПН до Сервера №1, и на котором прописаны необходимые маршруты до конечной точки.
Между маршрутизатором и Сервером №1 — IPSEC и необходимые маршруты
Между Сервером №1 и Сервером №2 — IPSEC и необходимые маршруты
Тогда с точки зрения клиента — он просто коннектится к нужному ему ресурсу в конечной точке
Клиент делает попытку коннекта
Пакет идет в шлюз по умолчанию, т.е. на маршрутизатор.
Маршрутизатор понимает, что пакет нужно доставить в ВПН №1
Маршрутизатор поднимает ВПН до Сервера №1 и отдает ему пакет
Сервер №1 понимает, что пакет нужно передать в ВПН №2
Сервер №1 поднимает ВПН №2 до Сервера №2 и отдает ему пакет
Сервер №2 отдает пакет в свою сеть.
в этой схеме, похоже, с точки зрения машин в частной сети в нске у всех клиентов будет один ip-адрес — тот который мы машине с Debian выдадим в VPN №2? это не подходит…
Клиент сел на лошадь, на перевале ему дали другую лошадь.
Лицо же у клиента от этого не поменяется.
Тут точно также. НАТа нет, есть просто два туннеля и маршруты.
видимо потому что я нихрена не понимаю в этой кухне )))
ну вот смотрите, в текущей схеме, клиент цепляется к серверу на Freebsd — сервер выдает ему IP из внутренней сети, все радуются.
в вашей схеме — клиент цепляется к серверу на Debian — сервер выдает ему IP из своей сети.
затем сервер соединяется с сервером на Freebsd (под одним и тем же логином для всех юзеров, насколько я понимаю, и это тоже печально), и получает для себя IP из целевой внутренней сети.
кто и когда выделит IP из целевой внутренней сети каждому подключившемуся клиенту?
вы так качественно даёте возможность почувствовать себя тупым ))))
Пока картинка обдумывается :)
Клиент приходит в конечную сеть со своим собственным ИПом.
IPSEC туннель связывает сети и не маскарадит адрес, он работает как транспорт
Средний
Простой
