У меня есть сервер с Pi-Hole, настроенный на блокировку рекламы и трекеров. Клиенты подключаются через OpenVPN и получают адреса из 10.8.0.0/24. OpenVPN только передает DNS клиенту, а трафик маршрутизируется через локальный шлюз, но, конечно, каждый клиент в VPN может связаться с любым другим клиентом через свои адреса 10.8.0.x.
Я заказал второй ipv4, который я хотел бы использовать специально для клиента 10.8.0.4. Я хочу иметь возможность доступа к публичному ip и выставлять этого клиента напрямую в интернет для использования локально размещенного Nextcloud.
Я искал Server Fault и нашел несколько похожих проблем. Я пытался добавить правила POSTROUTING и PREROUTING в iptables, но это не сработало. В настоящее время ipv4 временно добавлен в eth0 через 'ip addr add xx.xx.xx.xx. dev eth0', а не tun0 (это правильно?). Сервер OpenVPN настроен точно так, как указано в документации Pi-Hole (https://docs.pi-hole.net/guides/vpn/openvpn/only-dns-via-vpn/). net.ipv4.ip_forward включен.
Мне вообще нужно использовать iptables? Возможно ли или рекомендуется ли добавлять публичный ip к маршруту или что-то в этом роде? Извините, если вопрос звучит глупо. Я новичок в OpenVPN и настройке маршрута/iptables.
Это первое, что я попробовал:Перенаправить весь входящий трафик со вторичного публичного IP-адреса на внутренний IP-адрес с помощью iptables
Мои текущие правила iptables таковы:
# Generated by xtables-save v1.8.2 on Thu Dec 12 14:37:26 2019
*nat
:PREROUTING ACCEPT [329:28209]
:INPUT ACCEPT [281:25114]
:POSTROUTING ACCEPT [17:1423]
:OUTPUT ACCEPT [245:22126]
-A POSTROUTING -s 10.8.0.0/24 ! -d 10.8.0.0/24 -j SNAT --to-source xx.xx.xx.xx
-A POSTROUTING -o eth0 -j MASQUERADE
COMMIT
# Completed on Thu Dec 12 14:37:26 2019
# Generated by xtables-save v1.8.2 on Thu Dec 12 14:37:26 2019
*filter
:INPUT DROP [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i tun0 -j ACCEPT
-A INPUT -i tun0 -p tcp -m tcp --dport 53 -j ACCEPT
-A INPUT -i tun0 -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -i tun0 -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -i tun0 -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 2202 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 1194 -j ACCEPT
-A INPUT -p udp -m udp --dport 1194 -j ACCEPT
-A INPUT -p udp -m udp --dport 80 -j REJECT --reject-with icmp-port-unreachable
-A INPUT -p udp -m udp --dport 443 -j REJECT --reject-with icmp-port-unreachable
COMMIT
# Completed on Thu Dec 12 14:37:26 2019
Правила NAT iptables:
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
SNAT all -- 10.8.0.0/24 !10.8.0.0/24 to:xx.xx.xx.xx
MASQUERADE all -- anywhere anywhere
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
После комментария от NiKiZe я временно добавил публичный IP-адрес через
ip addr add xx.xx.xx.xx dev eth0
и ввел оба правила (для ясности: я экспортировал рабочий набор правил через iptables-save, отредактировал обе команды и восстановил его через iptables-restore)
-A PREROUTING -d xx.xx.xx.xx -j DNAT --to-destination 10.8.0.4
-A POSTROUTING -s 10.8.0.4 ! -d 10.8.0.4 -j SNAT --to-source xx.xx.xx.xx
Затем я открыл несколько терминальных сеансов и отслеживал веб-трафик с помощью tcpdump на сервере OpenVPN и моем локальном сервере, подтверждая, что входящий трафик на eth0 на pi.hole.http правильно направляется на мой локальный сервер server.vpn.http. Но ответ истекает по тайм-ауту...
Мои текущие правила NAT:
user@dns:~# iptables -t nat -vL --line-numbers
Chain PREROUTING (policy ACCEPT 1 packets, 52 bytes)
num pkts bytes target prot opt in out source destination
1 0 0 DNAT all -- any any anywhere pi.hole to:10.8.0.4
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 1 packets, 60 bytes)
num pkts bytes target prot opt in out source destination
1 0 0 SNAT all -- any any server.vpn !server.vpn to:xx.xx.xx.xx <- temporarily added ip address
2 0 0 SNAT all -- any any 10.8.0.0/24 !10.8.0.0/24 to:xx.xx.xx.xx <- main ip address, statically entered
3 0 0 MASQUERADE all -- any eth0 anywhere anywhere
Chain OUTPUT (policy ACCEPT 1 packets, 60 bytes)
num pkts bytes target prot opt in out source destination
Еще одно изменение: когда я добавляю 'src server.vpn' в tcpdump, я вижу, что исходящего трафика с локального сервера нет. Так что проблема либо в конфигурации локального сервера, либо в правиле postrouting. Я прав?
После изменения маршрута на server.vpn соединение работает. 'route -n' До:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.178.1 0.0.0.0 UG 0 0 0 eth0
10.8.0.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth3
169.254.160.0 169.254.160.1 255.255.248.0 UG 0 0 0 tun1000
169.254.160.0 0.0.0.0 255.255.248.0 U 0 0 0 tun1000
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
192.168.178.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
И после:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.8.0.1 0.0.0.0 UG 0 0 0 tun0
10.8.0.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth3
169.254.160.0 169.254.160.1 255.255.248.0 UG 0 0 0 tun1000
169.254.160.0 0.0.0.0 255.255.248.0 U 0 0 0 tun1000
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
192.168.178.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
Если я правильно понимаю, это означает, что КАЖДОЕ сетевое соединение, даже инициированное server.vpn, маршрутизируется через VPN. Это не ожидаемое поведение. Я просто хочу, чтобы сервер был доступен локально и использовал обычный, локально маршрутизируемый интернет, а также отвечал на соединения, маршрутизируемые с публичного IP на сервере OpenVPN.