Назад | Перейти на главную страницу

Пересылка OpenVPN продолжает перенаправлять меня на сам сервер (с openVZ)

Я пытаюсь настроить VPN на новом виртуальном сервере, работающем с OpenVZ. Я взял конфигурацию моей текущей VPN, которая размещена на Xen VPS, и вставил ее на свой новый сервер. После многих попыток я смотрю на разные темы и вижу, что OpenVZ не поддерживает MASQUERADE вариант iptables. Поэтому я пытаюсь создать файл iptable.sh, следуя это сообщение в блоге.

Когда я подключаюсь к VPN, каждая страница получено с моего веб-сервера (на той же машине, что и VPN) ... Например, если я попытаюсь получить доступ к http://www.google.com, Я вижу страницу по умолчанию "Работает" запущенного сервера Apache2. Не совсем понимаю, почему ... Вот моя конфигурация:

/etc/openvpn/server.conf

mode server
tls-server

port 10735
proto udp

dev tun0

# Certificates, blablah...

# Virtual addr conf
server 172.16.0.0 255.255.255.0

push "route 192.168.0.0 255.255.255.0"
push "dhcp-option DNS 8.8.8.8"

# Log, persitent connections, max clients, blabla..

Старый конфиг iptable (на моем предыдущем сервере с работающим MASQUERADE)

iptables -A FORWARD -s 172.16.0.0/24 -o eth0 -j ACCEPT
iptables -t nat -A POSTROUTING -s 172.16.0.0/24 -o eth0 -j MASQUERADE

Новая конфигурация iptables (хранится в файле .sh)

/sbin/iptables -F
/sbin/iptables -P OUTPUT ACCEPT

/sbin/iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
/sbin/iptables -A FORWARD -s 172.16.0.0/24 -j ACCEPT

#/sbin/iptables -A FORWARD -j REJECT

# Perform NATing on outgoing packets to change the IP address the packets come from
/sbin/iptables -t nat -A POSTROUTING -s 172.16.0.0/24 -j SNAT --to-source 89.2xx.xxx.xxx  <- my public addr

/sbin/iptables -A INPUT -p udp --dport 10735 -j ACCEPT
/sbin/iptables -A INPUT -p icmp -j ACCEPT
/sbin/iptables -A INPUT -i lo -j ACCEPT
/sbin/iptables -A INPUT -i tun0 -j ACCEPT
/sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

Заранее спасибо :)

Additional information

Разница между SNAT и MASQUERADE: первый работает быстрее, а второй работает с динамическим IP-адресом WAN (с использованием поиска в таблице маршрутов).
Многие из облачных VPS-сервисов, такие как Amazon, настраивают DMZ для вас: поэтому ваш внешний IP-адрес не является вашим IP-адресом на внешнем интерфейсе вашего сервера. Все соединения с любым портом переадресовываются с вашего 89.2xx.xxx.xxx (который действительно используется сетевым оборудованием) на ваш WAN iface.
Таким образом, TCP-запрос на http: // 'public VPS IP' будет обработан провайдером и безоговорочно перенаправлен на ваш eth0. Вот почему вы видите «это работает».
Но если вы попытаетесь установить в поле IP SOURCE всех исходящих пакетов значение 89.2xx.xxx.xxx - сеть провайдера оценит его как поддельный пакет и отбросит его.
Таким образом, вы должны использовать IP-адрес, назначенный вашему eth0 iface для SNAT (я думаю, он отличается от внешнего).

Убедитесь, что ваша подсеть eth0 не пересекает вашу подсеть VPN - 172.16.0.0

Что ж, согласно симптомам, которые вы описываете, ваш брандмауэр, похоже, имеет правило DNAT, перенаправляющее доступ извне на внутренний IP-адрес: 80. Это правило не учитывает входящий интерфейс, поэтому все ваши исходящие запросы также подвергаются DNAT. Такой тип перенаправления DNAT нужно использовать только на внешнем интерфейсе.

У меня есть сервер OpenVPN, настроенный через VPS, и мне пришлось использовать следующую команду, чтобы заставить NAT работать, поскольку MASQUERADE не будет. Как только я вставил его и убедился, что разрешил правила пересылки, а также включил ip_forward в /etc/sysctl.conf, я был готов к работе.

/sbin/iptables -t nat -A POSTROUTING -j SNAT --to-source external_ip_of_the_server