В рубрику "OpenVPN".
В очередной раз относительно случайно обнаружил крайне неприятную фичу Windows (у меня проявилось на Windows 7 x64 и Windows 8 x64), которая очень гадким способом влияет на работоспособность OpenVPN-клиента под оной операционной системой.
Косяк проявляется только в том случае, если соединение с Интернетом осуществляется с участием протокола PPP: либо через GPRS/3G модем, либо посредством PPTP или L2TP-тоннеля с провайдером (например, домашний интернет Билайн) и всё в этом духе. Суть там в том, что при наличии активного PPP-соединения Windows назначает метрики всех сетевых интерфейсов интерфейсов так, как хочется ей, а не так, как хочется пользователю. Это распространяется как на сам PPP-тоннель, так и на все остальные адаптеры, и плевать она хотела на то, что об этом всём думает пользователь.
Результат оказывается весьма плачевным. Так, например, если линк в Сеть поднят через "традиционный" Ethernet, то лог OpenVPN-а (подробность 4-го уровня) выглядит как-то так:
Wed Dec 25 10:12:06 2013 us=795748 Successful ARP Flush on interface [23] {9B1CC776-6595-4320-B092-96C567841997}
Wed Dec 25 10:12:11 2013 us=849888 TEST ROUTES: 3/3 succeeded len=3 ret=1 a=0 u/d=up
Wed Dec 25 10:12:11 2013 us=849888 C:\Windows\system32\route.exe ADD 192.168.70.1 MASK 255.255.255.255 192.168.70.13
Wed Dec 25 10:12:11 2013 us=849888 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=30 and dwForwardType=4
Wed Dec 25 10:12:11 2013 us=849888 Route addition via IPAPI succeeded [adaptive]
Wed Dec 25 10:12:11 2013 us=849888 C:\Windows\system32\route.exe ADD 192.168.9.8 MASK 255.255.255.255 192.168.70.13
Wed Dec 25 10:12:11 2013 us=849888 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=30 and dwForwardType=4
Wed Dec 25 10:12:11 2013 us=849888 Route addition via IPAPI succeeded [adaptive]
Wed Dec 25 10:12:11 2013 us=849888 C:\Windows\system32\route.exe ADD 192.168.9.9 MASK 255.255.255.255 192.168.70.13
Wed Dec 25 10:12:11 2013 us=849888 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=30 and dwForwardType=4
Wed Dec 25 10:12:11 2013 us=865488 Route addition via IPAPI succeeded [adaptive]
Wed Dec 25 10:12:11 2013 us=865488 Initialization Sequence Completed
Как видим, всё шоколадно. Если же линк в Сеть в том или ином виде использует PPP, то лог OpenVPN-а на при прочих равных условиях выглядит уже вот так:
Wed Dec 25 10:16:18 2013 us=629673 Successful ARP Flush on interface [23] {9B1CC776-6595-4320-B092-96C567841997}
Wed Dec 25 10:16:23 2013 us=684235 TEST ROUTES: 3/3 succeeded len=3 ret=1 a=0 u/d=up
Wed Dec 25 10:16:23 2013 us=684235 C:\Windows\system32\route.exe ADD 192.168.70.1 MASK 255.255.255.255 192.168.70.13
Wed Dec 25 10:16:23 2013 us=699835 ROUTE: route addition failed using CreateIpForwardEntry: Íåâåðíû îäèí èëè íåñêîëüêî àðãóìåíòîâ. [status=160 if_index=23]
Wed Dec 25 10:16:23 2013 us=699835 Route addition via IPAPI failed [adaptive]
Wed Dec 25 10:16:23 2013 us=699835 Route addition fallback to route.exe
Wed Dec 25 10:16:23 2013 us=699835 env_block: add PATH=C:\Windows\System32;C:\WINDOWS;C:\W
Wed Dec 25 10:16:23 2013 us=731036 C:\Windows\system32\route.exe ADD 192.168.9.8 MASK 255.255.255.255 192.168.70.13
Wed Dec 25 10:16:23 2013 us=746637 ROUTE: route addition failed using CreateIpForwardEntry: Íåâåðíû îäèí èëè íåñêîëüêî àðãóìåíòîâ. [status=160 if_index=23]
Wed Dec 25 10:16:23 2013 us=762237 Route addition via IPAPI failed [adaptive]
Wed Dec 25 10:16:23 2013 us=762237 Route addition fallback to route.exe
Wed Dec 25 10:16:23 2013 us=762237 env_block: add PATH=C:\Windows\System32;C:\WINDOWS;C:\W
Wed Dec 25 10:16:23 2013 us=777838 C:\Windows\system32\route.exe ADD 192.168.9.9 MASK 255.255.255.255 192.168.70.13
Wed Dec 25 10:16:23 2013 us=793438 ROUTE: route addition failed using CreateIpForwardEntry: Íåâåðíû îäèí èëè íåñêîëüêî àðãóìåíòîâ. [status=160 if_index=23]
Wed Dec 25 10:16:23 2013 us=793438 Route addition via IPAPI failed [adaptive]
Wed Dec 25 10:16:23 2013 us=809039 Route addition fallback to route.exe
Wed Dec 25 10:16:23 2013 us=809039 env_block: add PATH=C:\Windows\System32;C:\WINDOWS;C:\W
Wed Dec 25 10:16:23 2013 us=824639 Initialization Sequence Completed
Как видим, всё плохо. "Спущенные" с сервера статические маршруты в системе не прописались, или прописались криво. Повторяю, в обоих экспериментах всё идентичное за исключением способа подключения к Интернету.
Во втором случае OpenVPN не смог корректно совершить вызов IPAPI-функций. Некстати, проблема — боян, и тянется нерешенной ажно с 2005-го года. В качестве костыля (Workaround-а) в конфиг OpenVPN-клиента предлагается добавить вот такие строчки:
setenv PATH "C:\\Windows\\System32;C:\\WINDOWS;C:\\W
route-method exe
route-delay 3
Казалось бы, проблема решена? Ха-ха, щаззз там! Это только цветочки. Как я уже упоминал, винда думает, что она умнее всех и сама расставляет метрики на интерфейсы. В итоге, если вы хотите использовать на клиенте свой собственный DNS-сервер вместо провайдерского, то вы... жестоко обломаетесь. Допустим, вы спустите с OpenVPN-терминатора директивы типа
push "dhcp-option DOMAIN my.company.local"
push "dhcp-option DNS 192.168.9.8"
или пропишете их же в локальных конфигах. А пофигу! Винда будет использовать тот DNS-сервер, со стороны которого метрика на интерфейсе меньше. Несложно догадаться, что им всегда окажется DNS вашего провайдера. В любом случае. Потому что винда всегда присвоит минимальную метрику PPP-интерфейсу и никакими способами нельзя заставить её вести себя по-другому.
Сделаем последнюю попытку пободатся с настырной виндой и пропишем в конфиге на клиенте что-нибудь типа
route 192.168.15.0 255.255.255.0 remote_host 2
По задумке, последнее число в этой строке должно означать метрику этого маршрута. Можете проверить в документации к OpenVPN. Но нет, опять же, пофигу. Класть хотела винда большой болт на все наши потуги.
Вконец отчаявшись, попробуем руками, уже после успешного установления тоннеля, сами в командной строке (консоли) произнести заклинание вроде
route add 192.168.15.6 192.168.39.1 METRIC 2
Результат? Винда скажет "окей", и маршрут добавится с той метрикой, которую пожелает она сама, а не с той, которую указали мы. И эта метрика, к гадалке не ходи, всё равно будет больше (то есть менее приоритетной) относительно той, что на PPP-интерфейсе.
Все желающие могут проверить самостоятельно всё вышеизложенное. Для этого необязательно даже устанавливать OpenVPN на свой компьютер. Достаточно создать любое PPP-подключение, активировать его и посмотреть на то, как поведут себя при этом метрики всех остальных интерфейсов. Ради фана можете попытаться поменять их. Скажу сразу: ничего не получится.
В-общем, как говорится, "я сел на задницу". С учетом всего вышеизложенного представляется затруднительным использование под виндой любого софта, который так или иначе задействует виртуальные сетевые адаптеры. И что с этим всем делать, ни фига не понятно.