Про OpenVPN
Nov. 4th, 2013 02:35 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
vitus_wagnerПрошло немногим более двух лет с тех пор как я предлагал моим комментаторам помочь в проектировании VPN и я VPN всё-таки насторил.
Результат, правда, получился хуже, чем формулировались требования в том ТЗ, но жить вроде можно.
Конструкция следующая:
1. dhcpd в локальной сети выполняет ddns update на локальном же неймсервере.
Собственно, все недостатки получившейся системы связаны в основном с тем, когда isc dhcpd выполняет dns update, а когда отказывается.
2. У openvpn на хостинговой машине есть client-connect скрипт, который, помимо всего прочего, выполняет nsupdate, вписывая CN-ы сертификатов своих клиентов в DNS домашней сети. (в предположении что VPN между хостинговым сервером и домашней машной в момент коннекта внещего клиента поднята).
3. У openvpn есть еще и disconnect скрипт, который чистит из DNS следы присутствия клиента. Иначе DHCPD потом откажется апдейтить DNS для этого имени. Скажет "не моя A-запись".
3. У VPN-сервера ifconfig pool и пул адресов домашней сети - разные (хотя и случайно смежные) диапазоны адресов.
В чем недостатки получившейся конструкции:
1. При подключении машины к локальной через разные интерфейсы (ethernet и wifi) она получает разные адреса, и только первый из них прописывается в DNS с её хостнеймом.
При подключении через второй интерфейс получается другой dhcpid и dhcpd отказывается апдейтить запись, оставшуюся от первого интерфейса. Собственно из-за этого я так долго использовал назначение статических адресов по dhcp-client-identifier. Потому что на тех ОС, где его можно задать, он задается руками и независим от MAC адреса интерфейса.
2. При наличии на машине дуалбута (два года назад эта проблема не стояла) у разных операционных систем получается разный dhcpid. Поэтому после перезагрузки машина получает другой адрес который в DNS с её хостнеймом не прописывается.
А все потому что в схему обновления DNS interim в isc dhcpd заложена немерянная паранойя с защитой от подмены хостнейма. Вариант что у кого-то в модели угроз этой угрозы просто нет авторы почему-то не рассматривали. При этом схему ad hoc они поддерживтать не хотят. Пишут жирными буквами в man-е "it doesn't work".
Прямо хоть пиши какой-нибудь самопальный скрипт, который отслеживает то ли DHCPACK в логе, то-ли обновления leases и зовет nsupdate. Безо всякой паранойи.
Но засада еще в том, что есть андроид-устройства, хостнеймы у которых владельцем устройсва не контролируются. Сейчас они описаны в dhcpd.conf как хосты с явно заданным ddns name. А так придется держать их в каком-то более другом конфиге.
Про который я, естественно, буду полчаса вспоминать с матом через год, когда в доме заведется ещё одно андроидное устройство и его потребуется обозвать.
Результат, правда, получился хуже, чем формулировались требования в том ТЗ, но жить вроде можно.
Конструкция следующая:
1. dhcpd в локальной сети выполняет ddns update на локальном же неймсервере.
Собственно, все недостатки получившейся системы связаны в основном с тем, когда isc dhcpd выполняет dns update, а когда отказывается.
2. У openvpn на хостинговой машине есть client-connect скрипт, который, помимо всего прочего, выполняет nsupdate, вписывая CN-ы сертификатов своих клиентов в DNS домашней сети. (в предположении что VPN между хостинговым сервером и домашней машной в момент коннекта внещего клиента поднята).
3. У openvpn есть еще и disconnect скрипт, который чистит из DNS следы присутствия клиента. Иначе DHCPD потом откажется апдейтить DNS для этого имени. Скажет "не моя A-запись".
3. У VPN-сервера ifconfig pool и пул адресов домашней сети - разные (хотя и случайно смежные) диапазоны адресов.
В чем недостатки получившейся конструкции:
1. При подключении машины к локальной через разные интерфейсы (ethernet и wifi) она получает разные адреса, и только первый из них прописывается в DNS с её хостнеймом.
При подключении через второй интерфейс получается другой dhcpid и dhcpd отказывается апдейтить запись, оставшуюся от первого интерфейса. Собственно из-за этого я так долго использовал назначение статических адресов по dhcp-client-identifier. Потому что на тех ОС, где его можно задать, он задается руками и независим от MAC адреса интерфейса.
2. При наличии на машине дуалбута (два года назад эта проблема не стояла) у разных операционных систем получается разный dhcpid. Поэтому после перезагрузки машина получает другой адрес который в DNS с её хостнеймом не прописывается.
А все потому что в схему обновления DNS interim в isc dhcpd заложена немерянная паранойя с защитой от подмены хостнейма. Вариант что у кого-то в модели угроз этой угрозы просто нет авторы почему-то не рассматривали. При этом схему ad hoc они поддерживтать не хотят. Пишут жирными буквами в man-е "it doesn't work".
Прямо хоть пиши какой-нибудь самопальный скрипт, который отслеживает то ли DHCPACK в логе, то-ли обновления leases и зовет nsupdate. Безо всякой паранойи.
Но засада еще в том, что есть андроид-устройства, хостнеймы у которых владельцем устройсва не контролируются. Сейчас они описаны в dhcpd.conf как хосты с явно заданным ddns name. А так придется держать их в каком-то более другом конфиге.
Про который я, естественно, буду полчаса вспоминать с матом через год, когда в доме заведется ещё одно андроидное устройство и его потребуется обозвать.
