У меня есть сервер с 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-через-vpn/). net.ipv4.ip_forward включен.
Мне вообще нужно использовать iptables? Возможно ли или рекомендуется добавить публичный IP-адрес в маршрут или что-то в этом роде? Извините, если вопрос звучит глупо. Я новичок в настройке OpenVPN и Route/iptables.
Это первое, что я попробовал: Перенаправить весь входящий трафик со вторичного общедоступного IP-адреса на внутренний IP-адрес с помощью iptables.
Мои текущие правила iptables:
# Сгенерировано xtables-save v1.8.2, четверг, 12 декабря, 14:37:26 2019 г.
*натуральный
: ПРЕДВАРИТЕЛЬНОЕ ПРИНЯТИЕ [329:28209]
:ВВОД ПРИНЯТ [281:25114]
:ОТПРАВКА ПРИНЯТИЯ [17:1423]
: ВЫВОД ПРИНЯТ [245:22126]
-A РАЗМЕЩЕНИЕ -s 10.8.0.0/24 ! -d 10.8.0.0/24 -j SNAT --to-source xx.xx.xx.xx
-A ПОСТРОЙКА -o eth0 -j МАСКАРАД
СОВЕРШИТЬ
# Завершено в четверг, 12 декабря, 14:37:26 2019 г.
# Сгенерировано xtables-save v1.8.2, четверг, 12 декабря, 14:37:26 2019 г.
*фильтр
:ВХОД ПАДЕНИЕ [0:0]
:ВПЕРЕД ПРИНЯТЬ [0:0]
: ВЫВОД ПРИНЯТЬ [0:0]
-A ВВОД -i lo -j ПРИНЯТЬ
-A ВВОД -m состояние --state СВЯЗАННО, УСТАНОВЛЕНО -j ПРИНЯТЬ
-A ВВОД -i tun0 -j ПРИНЯТЬ
-A INPUT -i tun0 -p tcp -m tcp --dport 53 -j ПРИНЯТЬ
-A INPUT -i tun0 -p udp -m udp --dport 53 -j ПРИНЯТЬ
-A INPUT -i tun0 -p tcp -m tcp --dport 80 -j ПРИНЯТЬ
-A INPUT -i eth0 -p tcp -m tcp --dport 80 -j ПРИНЯТЬ
-A INPUT -i tun0 -p tcp -m tcp --dport 443 -j ПРИНЯТЬ
-A INPUT -i eth0 -p tcp -m tcp --dport 443 -j ПРИНЯТЬ
-A ВХОД -p tcp -m tcp --dport 2202 -j ПРИНЯТЬ
-A ВХОД -p tcp -m tcp --dport 1194 -j ПРИНЯТЬ
-A ВВОД -p udp -m udp --dport 1194 -j ПРИНЯТЬ
-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
СОВЕРШИТЬ
# Завершено в четверг, 12 декабря, 14:37:26 2019 г.
Правила NAT iptables:
Цепь PREROUTING (политика ПРИНЯТЬ)
целевая защита выбор источника назначения
Сеть INPUT (политика ACCEPT)
целевая защита выбор источника назначения
Сеть POSTROUTING (правило ПРИНЯТЬ)
целевая защита выбор источника назначения
SNAT все -- 10.8.0.0/24 !10.8.0.0/24 до:xx.xx.xx.xx
МАСКАРАДируйте все -- где угодно и где угодно
Цепочка OUTPUT (политика ACCEPT)
целевая защита выбор источника назначения
После комментария от NiKiZe я временно добавил публичный IP-адрес через
IP-адрес добавить 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 ОТПРАВКА -s 10.8.0.4 ! -d 10.8.0.4 -j SNAT --к источнику xx.xx.xx.xx
Затем я открыл несколько терминальных сеансов и отслеживал веб-трафик с помощью tcpdump на сервере OpenVPN и на моем локальном сервере, подтверждая, что входящий трафик с eth0 на pi.hole.http правильно направляется на мой локальный сервер server.vpn.http. Но время ответа истекает...
Мои текущие правила nat:
user@dns:~# iptables -t nat -vL --номера строк
Цепочка PREROUTING (политика ACCEPT 1 пакета, 52 байта)
num pkts bytes target prot opt in out source target
1 0 0 DNAT все -- любое любое любое место pi.hole to:10.8.0.4
Цепочка INPUT (политика ACCEPT 0 пакетов, 0 байтов)
num pkts bytes target prot opt in out source target
Цепочка POSTROUTING (политика ACCEPT 1 пакета, 60 байт)
num pkts bytes target prot opt in out source target
1 0 0 SNAT all -- any any server.vpn !server.vpn to:xx.xx.xx.xx <- временно добавленный IP-адрес
2 0 0 SNAT all -- any any 10.8.0.0/24 !10.8.0.0/24 to:xx.xx.xx.xx <- основной IP-адрес, введенный статически
3 0 0 MASQUERADE all -- любой eth0 в любом месте в любом месте
Цепочка OUTPUT (политика ACCEPT 1 пакета, 60 байт)
num pkts bytes target prot opt in out source target
Другое редактирование:
Когда я добавляю «src server.vpn» в tcpdump, я вижу, что с локального сервера нет исходящего трафика. Таким образом, должна быть проблема либо с конфигурацией локального сервера, либо с правилом постмаршрутизации. Я прав?
После смены маршрута на server.vpn соединение работает.
'маршрут -n' Раньше:
Таблица IP-маршрутизации ядра
Шлюз назначения Флаги Генмаски Метрика Ссылка Использование 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 УГ 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 докер0
192.168.178.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
И после:
Таблица IP-маршрутизации ядра
Шлюз назначения Флаги Генмаски Метрика Ссылка Использование 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 УГ 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 докер0
192.168.178.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
Если я правильно понимаю, это означает, что КАЖДОЕ сетевое соединение, даже инициированное server.vpn, маршрутизируется через VPN. Это не ожидаемое поведение. Я просто хочу, чтобы сервер был доступен локально и использовал обычный, локально маршрутизируемый Интернет, а также отвечал на соединения, маршрутизируемые с общедоступного IP-адреса на сервере OpenVPN.
