Прокладіть весь трафік через OpenVPN

Так, це питання було задано сто разів, і я шукав всюди, безрезультатно.

У заголовку все сказано насправді.

У мене є сервер OpenVPN (У ubuntu), і я можу підключитися до нього через мій клієнт (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.

Хтось мав цю проблему і встиг її вирішити?

Велике дякую

Я перевірив це за допомогою сервера 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-шлюза 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 команди як root

Команди:

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
• eth0: ваша звичайна мережева карта
• 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-запит не потрібен при розшифровці символів до чисел, і він надходить у загальний потік, як звичайний пакет даних.

Я буду радий знати ваші міркування, це не буде здивування, якщо я абсолютно помиляюся

Додайте таку директиву до файлу конфігурації сервера:

push "redirect-gateway def1"

Якщо ваш VPN налаштовано через бездротову мережу, де всі клієнти та сервер знаходяться в одній бездротовій підмережі, додайте локальний прапор:

push "redirect-gateway local def1"

При натисканні на опцію шлюзу переадресації клієнтам все трафік IP-мережі, що виникає на клієнтських машинах, проходить через сервер OpenVPN. Сервер повинен бути налаштований так, щоб якось справлятися з цим трафіком, наприклад, встановивши його в Інтернет або проклавши його через 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 (або подібній), є ще одна проблема, на яку слід стежити, порядок зв’язування NIC. Наявні параметри сервера DNS на LAN або адаптері Wi-Fi можуть мати пріоритет над параметрами сервера DNS для інтерфейсу тунелю, тому, хоча все налаштовано прямо з точки зору OpenVPN, Windows продовжує використовувати оригінальний DNS-сервер.

Ви можете виправити це, як описано в цій публікації на форумі Microsoft.

https://social.technet.microsoft.com/Forums/windowsserver/en-US/1cc5b647-6e51-482b-8998-ac5c3900938c/how-to-force-vpn-clients-to-use-the-dnsserver-from- їх-vpn-adapter-not-the-dnsserver-from-njihove? forum = winserverNIS

Я зіткнувся з тією ж проблемою і виявив, що при використанні сценарію настройки PiVPN для Open VPN конфігурація сервера містить рядок:

натиснути "перенаправлення-шлюз def1 bypass-dhcp"

вже. На клієнті IOS все проходить через тунель автоматично (саме так пише журнал).

На клієнті Tunnelblick потрібно додати цей рядок у client.ovpn рядок:

перенаправлення-шлюз def1 by1-dhcp

і це має працювати ідеально. Принаймні, це було на моєму Mac.