Маршрутизация интернет-трафика через VPN-туннель
Я относительно новичок в этой теме, поэтому, пожалуйста, не возражайте, если я задам простые (или глупые) вопросы. У меня есть Raspberry Pi 3B, и я установил и настроил на нем сервер OpenVPN. Поэтому я следовал этому руководству сообщества openvpn: https://openvpn.net/community-resources/how-to/ Я использую компьютер Windows для подключения к этому серверу, который отлично работает. Я попытался настроить сервер так, чтобы мой интернет-трафик IPv4 проходил через туннель. Проблема в том, что во время установления соединения с VPN-сервером веб-сайты IPv4 вообще не загружаются. Кроме того, трафик IPv6 по-прежнему проходит, так что веб-сайты IPv6 загружаются как обычно. Пожалуйста, найдите конфигурацию сервера, конфигурацию клиента, наборы правил iptables и таблицу IP-маршрутизации. В дополнение к этому я настроил NAT в соответствии с руководством сообщества с помощью команды
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
. Таким образом, проблема в конечном итоге заключается в правильной маршрутизации. Заранее благодарим всех за помощь!
Ура, Патрик
PS: 192.168.2.1 - это IP-адрес маршрутизатора W-Lan, к которому мой Pi подключен через Ethernet.
Конфигурация сервера
port 1194
proto udp
dev tun
ca /etc/openvpn/server/ca.crt
cert /etc/openvpn/server/server.crt
key /etc/openvpn/server/server.key
dh /etc/openvpn/server/dh.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist /var/log/openvpn/ipp.txt
keepalive 10 120
tls-auth /etc/openvpn/server/ta.key 0
cipher AES-256-CBC
user nobody
group nogroup
persist-key
persist-tun
status /var/log/openvpn/openvpn-status.log
verb 3
push "redirect-gateway local def1"
push "dhcp-options DNS 10.8.0.1"
Конфигурация клиента
client
dev tun
proto udp
remote 192.168.2.129 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert client.crt
key client.key
remote-cert-tls server
tls-auth ta.key 1
cipher AES-256-CBC
verb 3
redirect-gateway local def1
Правила IPv4
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -s 127.0.0.0/8 ! -i lo -j REJECT --reject-with icmp-port-unreachable
-A INPUT -p icmp -m state --state NEW -m icmp --icmp-type 8 -j ACCEPT
-A INPUT -p icmp -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i eth0 -p tcp -m state --state NEW,ESTABLISHED -m tcp --dport 22 -j ACCEPT
-A INPUT -i eth0 -p udp -m state --state NEW,ESTABLISHED -m udp --dport 1194 -j ACCEPT
-A INPUT -i eth0 -p tcp -m state --state NEW,ESTABLISHED -m tcp --dport 1194 -j ACCEPT
-A INPUT -i eth0 -p udp -m state --state ESTABLISHED -m udp --sport 53 -j ACCEPT
-A INPUT -i eth0 -p tcp -m state --state ESTABLISHED -m tcp --sport 80 -j ACCEPT
-A INPUT -i eth0 -p tcp -m state --state ESTABLISHED -m tcp --sport 443 -j ACCEPT
-A INPUT -i tun0 -j ACCEPT
-A INPUT -m limit --limit 3/min -j LOG --log-prefix "iptables_INPUT_denied: "
-A INPUT -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -m limit --limit 3/min -j LOG --log-prefix "iptables_FORWARD_denied: "
-A FORWARD -j REJECT --reject-with icmp-port-unreachable
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -p icmp -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m state --state ESTABLISHED -m tcp --sport 22 -j ACCEPT
-A OUTPUT -o eth0 -p udp -m state --state ESTABLISHED -m udp --sport 1194 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m state --state ESTABLISHED -m tcp --sport 1194 -j ACCEPT
-A OUTPUT -o eth0 -p udp -m state --state NEW,ESTABLISHED -m udp --dport 53 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m state --state NEW,ESTABLISHED -m tcp --dport 80 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m state --state NEW,ESTABLISHED -m tcp --dport 443 -j ACCEPT
-A OUTPUT -o tun0 -j ACCEPT
-A OUTPUT -m limit --limit 3/min -j LOG --log-prefix "iptables_OUTPUT_denied: "
-A OUTPUT -j REJECT --reject-with icmp-port-unreachable
COMMIT
Правила IPv6
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -j REJECT --reject-with icmp6-port-unreachable
-A FORWARD -j REJECT --reject-with icmp6-port-unreachable
-A OUTPUT -j REJECT --reject-with icmp6-port-unreachable
COMMIT
IP Таблица маршрутизации
Target Router Genmask Flags MSS Window irtt Iface
0.0.0.0 192.168.2.1 0.0.0.0 UG 0 0 0 eth0
10.8.0.0 10.8.0.2 255.255.255.0 UG 0 0 0 tun0
10.8.0.0.2 0.0.0.0 255.255.255.225 UH 0 0 0 tun0
192.168.2.1 0.0.0.0 255.255.255.0 U 0 0 0 eth0
Является ли таблица IP-маршрутизации с вашего компьютера Windows клиентом? Я прекрасно понимаю, почему они рекомендуют "def1". Для меня ваш вопрос довольно прост, ваш клиент Windows и ваш VPN-сервер находятся на 192.168.2.0/24 gw 192.168.2.1, и вам было бы лучше установить gw по умолчанию в качестве виртуального IP-адреса вашего vpn-сервера внутри туннеля, проверьте
ip addr
или просто добавьте журнал /var/ovpn.log в свою конфигурацию и проверьте настоящий IP-адрес. и, во-вторых, установите 192.168.2.1 как gw для сети 192.168.2.0/24 Как только вы настроите эту таблицу маршрутизации, Ваша машина Windows обнаружит, что 192.168.2.1 для доступа к вашему VPN-серверу, а любой другой трафик за пределами 192.168.2.0/24 идет на виртуальный IP-адрес этого сервера для маршрутизации.
Вы безоговорочно отклоняете трафик в прямой цепочке ваших iptables.
Если это действительно то, что вы хотите, это, вероятно, следует сделать следующим образом:
-N WHATEVER
-A WHATEVER -j LOG --log-prefix "iptables_FORWARD_denied: "
-A WHATEVER -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -m limit --limit 3/min -g WHATEVER
Чтобы вы не откажетесь безоговорочно. Я понятия не имею, является ли ограничение разумным / тем, что вы намереваетесь.
Также обратите внимание, что даже если это не то, что вы хотите, и вы отказались от всего этого, вам нужно убедиться, что переадресация IP не только разрешена ( в iptables) включенным (с помощью sysctl).
PS Не уверен, как избежать «утечки IPv6». Однако это может быть специфической проблемой системы (т.е. не проблемой OpenVPN).
Похоже, что конфигурация push-маршрутизатора подходит для клиента, это знает ваш компьютер Windows, и я может найти VPN-сервер на 10.8.0.1 в качестве маршрутизатора.
И что ваш пинг достигает google.com и 8.8.8.8, но вопрос в том, почему он не возвращается эхом?
traceroute to 8.8.8.8 (8.8.8.8), 64 hops max
-1 10.8.0.1 3.431ms 3.021ms 6.034ms
-2 * * *
......
-7 8.8.8.8 14.281ms 15.043ms 13.892ms
Я предполагаю, что основная причина заключается в том, что маскарад в iptables маскирует исходный IPv6 с вашей машины Windows с помощью IPv6 вашего Rasberry Pi, и эти веб-сайты отказываются отвечать на любой IPv6-адрес.
Дополнительная диагностика пакета, исходящего с вашей машины Pi, полезна, вы можете использовать ip addr или ifconfig , чтобы проверить [имя сетевой карты], начинающееся с «eth» и адрес после «inet» (ipv4) и раздел «inet6» (ipv6). И вы можете проверить реальный трафик, исходящий от вашего Pi, во время эхо-запроса от клиента Windows.
tcpdump icmp -nn -i [netcard's name] -v
И если вы обнаружите, что исходящий трафик получает адрес источника ipv6 вашего Pi, действительно, это причина. Чтобы исправить это, вы должны заменить предложение маскарада (удалить его), явно указав SNAT (изменение исходного IP-адреса) на его адрес ipv4:
iptables -t nat -A POSTROUTING -j SNAT -to [Pi's ipv4 address]
Проблема может быть в клиенте Windows 10. По умолчанию метрика интерфейса как для физического сетевого адаптера, так и для виртуального сетевого адаптера VPN имеет значение «Автоматически». Вам необходимо снять флажок «Автоматически» и ввести значение 50 для физического адаптера и 25 для виртуального адаптера VPN. Потом,откройте командную строку с запуском от имени администратора и введите команду ipconfig / flushdns .