☰

Разрешить OpenVPN через определенный порт - CentOS 6.5

tag-icon • tag-icon centos iptables openvpn odoo
Разрешить OpenVPN через определенный порт - CentOS 6.5

У меня есть VPS (CentOS 6.5). Я установил OpenVPN на этом сервере. Все работает отлично, я могу подключиться и серфить и т. д. Допустим, мой IP сервера: 1.2.3.4. Когда я подключаюсь к своему VPS, мой IP 1.2.3.4.

Я также установил OpenERP (на том же VPS), который работает на порту 8069.

Я пытаюсь заблокировать весь трафик на порту 8069, за исключением трафика VPN. Поэтому мне нужно подключиться к моему VPS с OpenVPN, чтобы получить доступ http://1.2.3.4:8069.

Я перепробовал несколько руководств по iptables в сети, но ни одно из них не работает.

Например:

iptables -A INPUT -p tcp -s 1.2.3.4 --dport 8069 -j ACCEPT 
or 
iptables -A INPUT -p tcp -s  10.8.0.0/24 --dport 8069 -j ACCEPT
or
iptables -I INPUT \! --src 10.8.0.0/24 -m tcp -p tcp --dport 8069 -j DROP
or
iptables -I INPUT \! --src 1.2.3.4 -m tcp -p tcp --dport 8069 -j DROP

Это примеры. Я пробовал даже больше правил. Все руководства, которым я следовал, блокируют весь трафик на порту 8069, даже если я подключаюсь к своему VPS с OpenVPN, я не могу получить доступ http://1.2.3.4:8069.

Есть ли у кого-нибудь идея, как заблокировать весь трафик на порту 8069, кроме моего VPN-подключения? Как мне этого добиться?

Мой server.conf такой:

port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh2048.pem
server 10.8.0.0 255.255.255.0
push "redirect-gateway def1"
push "dhcp-option DNS 10.8.0.1"
user nobody
group nobody
keepalive 5 30
cipher AES-256-CBC   
comp-lzo
persist-key
persist-tun
verb 5

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

dev tun
client
proto udp
remote 1.2.3.4
port 1194
resolv-retry infinite
nobind
redirect-gateway def1
persist-key
persist-tun
ca ca.crt
cert nika-pc.crt
key nika-pc.key
cipher AES-256-CBC   
comp-lzo
ns-cert-type server
verb 5

Заранее спасибо.

Редактировать:

Вывод: iptables -L -n -v

http://pastebin.com/RhzFBG8R

Вывод: iptables -L -n -v | head

http://pastebin.com/n6gLe68s

решение1

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

iptables -I INPUT 1 -p tcp -i tun+ --dport 8069 -j ACCEPT
iptables -I INPUT 2 -p tcp --dport 8069 -j REJECT

Редактировать: Я действительно призываю вас редактировать обновления в вашем вопросе, вместо того, чтобы оставлять бесконечную серию ссылок pastebin, которые могут остаться или не остаться на месте со временем. В любом случае, спасибо за новый вывод. Как вы можете видеть, количество пакетов по первому правилу равно нулю, чего определенно не происходит по второму правилу (полный отказ). Единственный оставшийся вывод заключается в том, что вы ошибаетесь относительно этого трафика, использующего соединение OpenVPN; он довольно явно идет через открытый текстовый интернет. Если вы хотите бытьполностьюконечно, добавьте третье правило между двумя вышеприведенными, с

iptables -I INPUT 2 -p tcp --dport 8069 -j LOG --log-prefix "CARROT: "

Если только это слово не CARROTбудет часто встречаться в ваших лог-файлах, то будет легко найти вывод этих совпадений в системных журналах ( /var/log/messagesили как syslogсчитает нужным /ваш дистрибутив), и они должны подтвердить, на какой интерфейс поступают отклоненные пакеты. Я не ожидаю, что это будет tun0.

решение2

Я добавляю ответ, потому что не могу добавить комментарий. Я думаю, что используемый протокол — udp, а не tcp, поэтому

iptables -I INPUT 1 -p udp -i tun+ --dport 8069 -j ACCEPT
iptables -I INPUT 2 -p udp --dport 8069 -j REJECT

Связанный контент