Направьте весь трафик через OpenVPN
Да, этот вопрос задали сто раз, и я искал везде, напрасно.
В заголовке говорится все это действительно.
У меня есть сервер OpenVPN (На человечности), и я могу соединиться с нею через свой клиент (Windows 8)...
Проблема запускается, когда я пытаюсь направить ВЕСЬ трафик через VPN.
Я добавил push флаги в server.conf:
push "redirect-gateway def1"
push "dhcp-option DNS 8.8.8.8"
Когда я соединяюсь от клиента, клиентских выводов:
Wed May 07 21:38:40 2014 SENT CONTROL [StretchVPN-CA]: 'PUSH_REQUEST' (status=1)
Wed May 07 21:38:41 2014 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS 8.8.8.8,route-gateway <Remote Router IP>,ping 10,ping-restart 120,ifconfig 192.168.0.201 255.255.255.0'
Wed May 07 21:38:41 2014 OPTIONS IMPORT: timers and/or timeouts modified
Wed May 07 21:38:41 2014 OPTIONS IMPORT: --ifconfig/up options modified
Wed May 07 21:38:41 2014 OPTIONS IMPORT: route options modified
Wed May 07 21:38:41 2014 OPTIONS IMPORT: route-related options modified
Wed May 07 21:38:41 2014 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Wed May 07 21:38:41 2014 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Wed May 07 21:38:41 2014 open_tun, tt->ipv6=0
Wed May 07 21:38:41 2014 TAP-WIN32 device [Local Area Connection 4] opened: \\.\Global\{1F145805-92FC-454E-8FD9-0A6017DD4AD1}.tap
Wed May 07 21:38:41 2014 TAP-Windows Driver Version 9.9
Wed May 07 21:38:41 2014 Notified TAP-Windows driver to set a DHCP IP/netmask of 192.168.0.201/255.255.255.0 on interface {1F145805-92FC-454E-8FD9-0A6017DD4AD1} [DHCP-serv: 192.168.0.0, lease-time: 31536000]
Wed May 07 21:38:41 2014 Successful ARP Flush on interface [35] {1F145805-92FC-454E-8FD9-0A6017DD4AD1}
Wed May 07 21:38:46 2014 TEST ROUTES: 1/1 succeeded len=0 ret=1 a=0 u/d=up
Wed May 07 21:38:46 2014 C:\WINDOWS\system32\route.exe ADD <Remote Router IP> MASK 255.255.255.255 172.20.10.1
Wed May 07 21:38:46 2014 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=25 and dwForwardType=4
Wed May 07 21:38:46 2014 Route addition via IPAPI succeeded [adaptive]
Wed May 07 21:38:46 2014 C:\WINDOWS\system32\route.exe ADD 0.0.0.0 MASK 128.0.0.0 192.168.0.3
Wed May 07 21:38:46 2014 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=30 and dwForwardType=4
Wed May 07 21:38:46 2014 Route addition via IPAPI succeeded [adaptive]
Wed May 07 21:38:46 2014 C:\WINDOWS\system32\route.exe ADD 128.0.0.0 MASK 128.0.0.0 192.168.0.3
Wed May 07 21:38:46 2014 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=30 and dwForwardType=4
Wed May 07 21:38:46 2014 Route addition via IPAPI succeeded [adaptive]
Wed May 07 21:38:46 2014 Initialization Sequence Completed
Я попытался использовать флаги на стороне клиента при открытии соединения:
openvpn --config "C:\Program Files\OpenVPN\config\client.ovpn" --redirect-gateway def1 --route-method exe
Но тем не менее, когда я перехожу к whatsmyip.org, это все еще говорит мой клиентский IP.
Кто-либо имел эту проблему и сумел решить ее?
Большое спасибо
6 ответов
Я протестировал это использование сервера OpenVPN и установку, шлюз перенаправления def1 опция в конфигурации клиента и сервера хорошо работает. Когда я получаю доступ whatismyip.org , я вижу свой IP сервера OpenVPN. Ниже клиентская конфигурация, которую я использую:
client
dev tun
proto udp
# THE IP OF THE REMOTE OPENVPN SERVER:
remote ip_address port
resolv-retry infinite
nobind
persist-key
persist-tun
# THE CSR FILE:
pkcs12 certificate.p12
ns-cert-type server
cipher AES-256-CBC
comp-lzo
redirect-gateway def1
verb 3
я протестировал также с добавлением шлюза перенаправления def1 опцию к команде openvpn и достиг того же результата. Конфигурация сервера:
port 1194
proto udp
dev tun
dh /etc/openvpn/easy-rsa/keys/dh1024.pem
ca /etc/openvpn/easy-rsa/keys/ca.crt
# ENSURE THE DOMAIN NAME/FILENAME IS CORRECT:
cert /etc/openvpn/easy-rsa/keys/cert.crt
key /etc/openvpn/easy-rsa/keys/cert.key
server 10.5.3.0 255.255.255.0
# YOUR LOCAL SERVER IP HERE:
client-config-dir ccd
route 10.5.3.0 255.255.255.0
ifconfig-pool-persist ipp.txt
cipher AES-256-CBC
comp-lzo
persist-key
persist-tun
status log/openvpn-status.log 5
status-version 2
log-append log/openvpn.log
verb 3 # verbose mode
management localhost port /etc/openvpn/management-password
# ROUTE THE CLIENT'S INTERNET ACCESS THROUGH THIS SERVER:
push "redirect-gateway def1"
push "remote-gateway vpn_server_ip"
push "dhcp-option DNS 8.8.8.8"
keepalive 10 60
Возможно, Вы забыли изменять свой NAT? Выполните те 3 команды как корень
Команды:
iptables -I FORWARD -i tun0 -o eth0 \
-s 10.8.0.0/24 -m conntrack --ctstate NEW -j ACCEPT
iptables -I FORWARD -m conntrack --ctstate RELATED,ESTABLISHED \
-j ACCEPT
iptables -t nat -I POSTROUTING -o eth0 \
-s 10.8.0.0/24 -j MASQUERADE
Подпись:
- tun0: Ваш виртуальный VPN networkcard
- eth0: Ваш нормальный networkcard
- 10.8.0.0: Ваш блок IP сети VPN
После трудного поиска ответа, кажется, что я решил это, возможно, частично, но по крайней мере очень просто:
я использую Xubuntu 14.04 и пакет OpenVPN из основного источника. В Настройки> Система> Сеть , я заменил предварительно установленный адрес DNS 127.0.1.1 Google 8.8.8.8, и теперь я вижу, что весь трафик проходит сервер VPN.
В таблице Wireshark такая строка как DNS отсутствует: все данные идут как TCP через зашифрованный канал. Я вижу DHCP и трафик DNS, когда я смотрю tun0 (внутренний ноутбук). Когда я исследую wlan0 трафик (внешний между ноутбуком и маршрутизатором WiFi), я только получаю серые пакеты TCP.
я думаю, что это происходит, потому что запрос DNS не необходим в декодировании символов к числам, и это входит в общий поток как обычный блок данных.
я буду рад знать Ваши соображения, это не будет удивление, если я буду абсолютно неправ
Я столкнулся с той же проблемой и узнал, когда использование сценария установки PiVPN для Открывает VPN, конфигурация сервера содержит строку:
нажатие "шлюз перенаправления def1 уже обходят-dhcp"
. На клиенте IOS все направляется через туннель автоматически (именно это журнал говорит).
На клиенте Tunnelblick необходимо добавить эту строку в client.ovpn строка:
шлюз перенаправления def1 обход-dhcp
и это должно работать отлично. По крайней мере, это сделало на моем Mac.
Добавьте следующую директиву к конфигурационному файлу сервера:
push "redirect-gateway def1"
Если Ваша установка VPN по беспроводной сети, где все клиенты и сервер находятся в той же беспроводной подсети, добавьте локальный флаг:
push "redirect-gateway local def1"
Продвижение опции шлюза перенаправления клиентам заставит весь сетевой трафик IP, происходящий на клиентских машинах проходить через сервер OpenVPN. Сервер должен будет быть настроен для контакта с этим трафиком так или иначе, такой как NATing это к Интернету или маршрутизации его через Прокси HTTP сайта сервера.
На Linux Вы могли использовать команду, такую как это к NAT трафик клиента VPN к Интернету:
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
Эта команда предполагает, что подсеть VPN является 10.8.0.0/24 (взятый из директивы сервера в конфигурации сервера OpenVPN) и что интерфейс локальной сети Ethernet является eth0.
Когда шлюз перенаправления будет использоваться, клиенты OpenVPN направят запросы DNS через VPN, и сервер VPN должен будет обработать их. Это может быть выполнено путем продвижения адреса сервера DNS соединяющимся клиентам, которые заменят их нормальные настройки сервера DNS в течение времени, когда VPN активна. Например:
push "dhcp-option DNS 10.8.0.1"
настроит клиенты Windows (или клиенты не-Windows с некоторыми дополнительными клиентскими сценариями) для использования 10.8.0.1 в качестве их сервера DNS. Любой адрес, который достижим от клиентов, может использоваться в качестве адреса сервера DNS.
Если Ваш клиент OpenVPN находится в Windows 10 (или подобный) существует другая проблема, чтобы не упустить, обязательный порядок NICs. Существующие настройки сервера DNS на LAN или адаптере Wi-Fi могут взять приоритет над настройками сервера DNS для туннельного интерфейса, поэтому даже при том, что все настраивается правильно с точки зрения OpenVPN, Windows продолжает использовать исходный сервер DNS.
Можно зафиксировать это, как описано в этом сообщении форума Microsoft.