Один из наших корпоративных веб-сайтов работает на сервере Linux, построенном на Apache2 и PHP5.
Доступ к нескольким веб-страницам возможен только из подсети OpenVPN. (адреса 10.8.0.1/24). Чтобы проверить каждый запрос, php скрипт сравнивает $_SERVER["REMOTE_ADDR"] значение, предоставленное apache, и решает разрешить или запретить дальнейшее выполнение.
Цель состоит в том, чтобы запретить доступ к этим страницам с устройств, не настроенных для работы через серверную VPN.
Сервер OpenVPN работает на той же машине, поэтому PHP получает адреса типа 10.8.0.25 от клиентов внутри VPN и реальные адреса для других запросов.
Тестируя эту систему, я обнаружил странную вещь: если я запрашиваю одну из этих «защищенных» страниц с помощью компьютера с Windows, подключенного к нашей сети OpenVPN, сервер может видеть реальный IP-адрес (не 10.8.0.xx), делая то же самое. на устройстве Android работает должным образом (сервер не может видеть реальный IP-адрес и получить 10.8.0.xx в php).
я использую OpenVPN Connect приложение на Android и OpenVPN GUI на окнах. В обоих случаях клиент направляет свой трафик через VPN-сервер, и "Какой у меня IP?" службы показывают адрес VPN, а не реальный адрес моего интернет-провайдера.
Но каким-то образом клиент Windows идентифицируется по своему реальному адресу (поставщику) на веб-сервере и не может получить доступ к защищенным страницам, независимо от того, включен или выключен VPN.
У меня есть подозрения, что OpenVPN не работает должным образом на этом ПК с Windows. Иначе почему сервер по-разному распознает vpn-клиентов Android и Windows?
Спасибо.
UPD: iptables -L на машине VPN / websrv
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT tcp -- 10.8.0.0/24 anywhere tcp dpts:63000:64000
REJECT tcp -- anywhere anywhere tcp dpts:63000:64000 reject-with icmp-port-unreachable
ACCEPT udp -- 10.8.0.0/24 anywhere udp dpts:64000:65000
REJECT tcp -- anywhere anywhere tcp dpts:64000:65000 reject-with icmp-port-unreachable
DROP all -- anywhere anywhere match-set banned_ips src
UPD :: cmd /k route print на машине Windows
Interface List
5...54 04 a6 3d 36 ff ......Realtek PCIe GBE Family Controller
7...fc 75 16 86 ad 84 ......Microsoft Wi-Fi Direct Virtual Adapter
17...00 ff b7 66 85 11 ......TAP-Windows Adapter V9
12...00 50 56 c0 00 01 ......VMware Virtual Ethernet Adapter for VMnet1
13...00 50 56 c0 00 08 ......VMware Virtual Ethernet Adapter for VMnet8
6...fc 75 16 86 ad 82 ......D-Link DWA-125 Wireless N 150 USB Adapter(rev.A3)
1...........................Software Loopback Interface 1
2...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter
3...00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface
11...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #2
18...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #3
8...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #4
===========================================================================
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.137.1 192.168.137.97 25
0.0.0.0 128.0.0.0 10.8.0.5 10.8.0.6 20
10.8.0.0 255.255.255.0 10.8.0.5 10.8.0.6 20
10.8.0.4 255.255.255.252 On-link 10.8.0.6 276
10.8.0.6 255.255.255.255 On-link 10.8.0.6 276
10.8.0.7 255.255.255.255 On-link 10.8.0.6 276
127.0.0.0 255.0.0.0 On-link 127.0.0.1 306
127.0.0.1 255.255.255.255 On-link 127.0.0.1 306
127.255.255.255 255.255.255.255 On-link 127.0.0.1 306
128.0.0.0 128.0.0.0 10.8.0.5 10.8.0.6 20
xxx.53.xxx.yy 255.255.255.255 192.168.137.1 192.168.137.97 25
192.168.10.0 255.255.255.0 10.8.0.5 10.8.0.6 20
192.168.20.0 255.255.255.0 10.8.0.5 10.8.0.6 20
192.168.137.0 255.255.255.0 On-link 192.168.137.97 281
192.168.137.97 255.255.255.255 On-link 192.168.137.97 281
192.168.137.255 255.255.255.255 On-link 192.168.137.97 281
192.168.171.0 255.255.255.0 On-link 192.168.171.1 276
192.168.171.1 255.255.255.255 On-link 192.168.171.1 276
192.168.171.255 255.255.255.255 On-link 192.168.171.1 276
192.168.229.0 255.255.255.0 On-link 192.168.229.1 276
192.168.229.1 255.255.255.255 On-link 192.168.229.1 276
192.168.229.255 255.255.255.255 On-link 192.168.229.1 276
224.0.0.0 240.0.0.0 On-link 127.0.0.1 306
224.0.0.0 240.0.0.0 On-link 192.168.171.1 276
224.0.0.0 240.0.0.0 On-link 192.168.229.1 276
224.0.0.0 240.0.0.0 On-link 10.8.0.6 276
224.0.0.0 240.0.0.0 On-link 192.168.137.97 281
255.255.255.255 255.255.255.255 On-link 127.0.0.1 306
255.255.255.255 255.255.255.255 On-link 192.168.171.1 276
255.255.255.255 255.255.255.255 On-link 192.168.229.1 276
255.255.255.255 255.255.255.255 On-link 10.8.0.6 276
255.255.255.255 255.255.255.255 On-link 192.168.137.97 281
===========================================================================
Persistent Routes:
None
IPv6 Route Table
xxx.53.xxx.yy - IP-адрес машины VPN / websrv.
UPD: Еще два факта - Веб-сервер и защищенные страницы используют сертификат SSL (https) - DNS на устройствах Windows / Android настроен только на Google DNS.
Ваш VPN использует подсеть 10.8.0.0/24, но для маршрута к адресу xxx.53.xxx.yy используется шлюз 192.168.137.1 вместо 10.8.0.5, что означает, что веб-запросы к серверу от клиента Windows идут через Интернет, а не через VPN. Чтобы исправить это, вам нужно либо отключить разделенное туннелирование в вашем клиенте Windows OpenVPN для отправки все ваш трафик через VPN или измените шлюз статического маршрута для xxx.53.xxx.yy на 10.8.0.5.
Я вижу просто проблему с DNS. Когда вы пытаетесь подключиться к веб-сайту, вы разрешаете IP-адрес в Интернете, а не IP-адрес VPN. Следующее: отредактируйте C: \ Windows \ System32 \ drivers \ etc \ hosts и добавьте запись вроде
10.8.0.X www.yourdomain.com
Это должно заставить машину Windows разрешить правильный IP-адрес и соответствующим образом маршрутизировать. Если это сработает, то вы должны настроить VPN-сервер, чтобы клиенты использовали DNS-сервер внутри 10.8.0.0/24 (я думаю, что dhcp-option - это имя директивы, но вам следует провести некоторое исследование). DNS-сервер должен быть настроен для разрешения www.yourdomain.com на IP-адрес вашего внутреннего сервера.
Установите привязку на Openvpn / веб-сервере. Добавьте зону для www.example.com, чтобы она указывала на внутренний IP-адрес веб-сервера, и установите серверы пересылки для 8.8.8.8 и 8.8.4.4, а также убедитесь, что он прослушивает и настроен как преобразователь для внутренних / VPN-подсетей.
Базовая зона для конкретного поддомена, при необходимости обязательно реплицируйте любые повторяющиеся данные.
named.conf.options
forwarders { 8.8.8.8; 8.8.4.4; };
allow-recursion { 10.8.0.0/24; };
allow-query { 10.8.0.0/24; };
listen-on { any; }
Файл зоны
$TTL 300
@ IN SOA www.example.com. dnsadmin.example.com. (
2015000000 ; serial, YYYYMMDDRR
8H ; refresh, seconds
2H ; retry, seconds
4W ; expire, seconds
1D ) ; minimum, seconds
@ IN NS ns1
ns1 IN A 10.8.0.5
@ IN A 10.8.0.5
убедитесь, что вы протестировали и настроили openvpn для проталкивания этого DNS-сервера.
На компьютере с Windows вы проверяли метрику и смотрели, имеет ли VPN-маршрут более низкую метрику, поэтому более высокий приоритет? Может быть, проблема в метрике.
Еще одна вещь, которую вы можете попробовать, - установить конфигурацию openvpn на сервере, чтобы клиенты перенаправляли ВЕСЬ трафик через VPN-соединение.