dns, vpn, vpnpptp и mandriva

[romkaromka]

Локальная сеть:
ip1
gate1
dns1
При поднятом vpn через pptp:
ip2
gate2
dns2

t-время

Пусть dns1=dns2, то (t (dns2 через gate1)<= t (dns2 через gate2)) or (t (dns2 через gate1)>= t (dns2 через gate2))
То есть время открытия сайтов может быть быстрее, если dns2 пустить через gate1, может и быть примерно одинаковым, а может быть и бесконечным.
По-умолчанию dns2 идет через gate2 (dns1 идет через gate1), и работает может и не всегда быстро, но время в бесконечность не уйдет, и сайт рано или поздно откроется.
Для того, чтобы поднялось vpn, выполняется t(dns1 через gate1), то есть в локальной сети dns1 способен функционировать как полноценный dns-сервер, а значит t не уйдет в бесконечность, и сайт откроется.

Может ли быть dns1<>dns2?
Всегда ли t(dns2 через gate1)<=t(dns2 через gate2) - ведь логично, что в локальной сети скорости выше внешних (либо равны), а потому отклик dns1,2-сервера быстрее (или равен)?
Может ли быть в частном случае у провайдера dns1 отсутствует, а адрес vpn-сервера квадрантами числовой, ведь при таком раскладе вроде как не будет локальных ресурсов, но будет внешка?
Может ли t уйти в бесконечность при любых таких раскладах таблицы маршрутизации для dns?
Всегда ли dns1-полноценный dns-сервер?

Планирую пустить все dns-сервера из /etc/resolv.conf или только текущий dns через шлюз локальной сети и думаю какие подводные камни могут быть на пути такого подхода.
Пустить их все в этот шлюз насовсем нельзя, так как там и чужие dns, но при поднятом vpn вроде как можно, а при выходе из vpn убирать их из таблицы маршрутизации.
Плюс ко всему Мандрива по-умолчанию работает с dns вообще безобразно. У меня 2 провайдера, соответственно и 2 dns в /etc/resolv.conf, последнее не верно, потому что у провайдеров по 2 dns. Мало того, Мандрива не знает какое dns из /etc/resolv.conf относится к какому провайдеру и случайным образом подсовывает dns от чужого провайдера.
Или если пустить только текущее dns в шлюз локальной сети, но оно может быть чужим. Можно маршрутизацию dns организовать через скрипты /etc/ppp/ip-down и /etc/ppp/ip-up, и тогда станет возможным пустить все dns из /etc/resolv.conf в локалку или только текущий dns, тогда при выходе из vpn маршрутизация вернется в исходное состояние.
Пускать весь /etc/resolv.conf в локалку не есть гуд, но и текущий dns пускать в локалку не есть гуд, так как не всегда он родной. Сложность также в том, что resolv.conf - динамический файл.

[olelukoie]

Очень "многа букав", и понял я далеко не все, но вот ответы на то, что я понял:
1. Mandriva "подсовывает" DNS не случайным образом, а в порядке подключения интерфейсов. Т.е. именно в этом порядке адреса попадают в /etc/resov.conf и затем читаются из него и используются.
2. Адреса DNS всегда статические, поэтому лучше всего прописать их статическую маршрутизацию через правильный локальный шлюз.
3. Если адресов DNS много и от разных провов, то может лучше вместо них воспользоваться bind, а адрес VPN-сервера также прописать статически? А для необходимых локальных ресурсов прописать айпишники с именами в /etc/hosts и тоже сделать статическую маршрутизацию через правильный шлюз?

[romkaromka]

Очень "многа букав", и понял я далеко не все, но вот ответы на то, что я понял:
1. Mandriva "подсовывает" DNS не случайным образом, а в порядке подключения интерфейсов. Т.е. именно в этом порядке адреса попадают в /etc/resov.conf и затем читаются из него и используются.

тогда почему у меня у обоих провайдеров адреса dns-серверов определяются по протоколу dhcp, и у 1-ого провайдера dns оказывается от 2-ого (то есть, видимо, от последнего подключенного) - то есть сеть по-умолчанию поднимается не на том dns? в мандриве явно отсутствует привязка dns к конкретному интерфейсу.

2. Адреса DNS всегда статические, поэтому лучше всего прописать их статическую маршрутизацию через правильный локальный шлюз.

но если скорость внешки равна скорости локалки, то есть ли смысл в такой записи? а что если я не тот dns пущу не в тот шлюз?

3. Если адресов DNS много и от разных провов, то может лучше вместо них воспользоваться bind, а адрес VPN-сервера также прописать статически? А для необходимых локальных ресурсов прописать айпишники с именами в /etc/hosts и тоже сделать статическую маршрутизацию через правильный шлюз?

а смысл записи адреса VPN-сервера статически в локальный шлюз, чем лучше? ведь до поднятия vpn он и так локален. а при поднятом vpn он доступен через внешку. скорость инета вырастет?
может будет лучше если имя VPN-сервера прописать в /etc/hosts, сопоставив в нем все айпишки адресу vpn-сервера? в этом случае vpn-сервер будет доступен всегда для пользователей по его имени и станет независим от dns-сервера.

[olelukoie]

Очень "многа букав", и понял я далеко не все, но вот ответы на то, что я понял:
1. Mandriva "подсовывает" DNS не случайным образом, а в порядке подключения интерфейсов. Т.е. именно в этом порядке адреса попадают в /etc/resov.conf и затем читаются из него и используются.

тогда почему у меня у обоих провайдеров адреса dns-серверов определяются по протоколу dhcp, и у 1-ого провайдера dns оказывается от 2-ого (то есть, видимо, от последнего подключенного) - то есть сеть по-умолчанию поднимается не на том dns? в мандриве явно отсутствует привязка dns к конкретному интерфейсу.

Что значит "привязка"? Адреса DNS либо прописываются в настройках интерфейса (ifcfg-<интерфейс>), либо берутся от DHCP. Но эти адреса всегда одни и те же. И мандрива тут совсем ни при чем, это стандартное поведение любого линукса, да и не только его.

2. Адреса DNS всегда статические, поэтому лучше всего прописать их статическую маршрутизацию через правильный локальный шлюз.

но если скорость внешки равна скорости локалки, то есть ли смысл в такой записи? а что если я не тот dns пущу не в тот шлюз?

Если скорость одинакова, то это все равно. Если Вы пропишете неправильный маршрут, то просто не получите доступ к DNS. Обычно DNS провайдера доступны только через локалку и при подключении VPN правильный маршрут должен создаваться сам. Ошибки могут возникать, только если два разных прова используют одинаковые адреса подсетей и маршруты одного забивают маршруты другого. Ну или скрипт подключения или сам DHCP прова не расчитан на такую ситуацию и неправильно прописывает маршруты.

3. Если адресов DNS много и от разных провов, то может лучше вместо них воспользоваться bind, а адрес VPN-сервера также прописать статически? А для необходимых локальных ресурсов прописать айпишники с именами в /etc/hosts и тоже сделать статическую маршрутизацию через правильный шлюз?

а смысл записи адреса VPN-сервера статически в локальный шлюз, чем лучше? ведь до поднятия vpn он и так локален. а при поднятом vpn он доступен через внешку. скорость инета вырастет?

Скорость - вряд ли, но вот у меня корбиновский L2TP без такого статического маршрута вообще не поднимается. А маршруты к корбиновским же PPTP-"брасам" выдаются по DHCP (подключите VPN и посмотрите таблицу маршрутов).

может будет лучше если имя VPN-сервера прописать в /etc/hosts, сопоставив в нем все айпишки адресу vpn-сервера? в этом случае vpn-сервер будет доступен всегда для пользователей по его имени и станет независим от dns-сервера.

Можно и так, но зачем Вам весь пул адресов VPN прова? Выберите один наиболее стабильный и используйте его. Меняется этот пул все равно крайне редко.

[romkaromka]

Я пишу программу, которая должна учесть все ньюансы работы с vpn через pptp в мире, рассмотреть все частные случаи.
Уточню:
У второго провайдера:
ip3
gate3
dns3
что будет если я пущу dns3 не в gate3, а в gate1 временно на период поднятия и работы интерфейса ppp0 на провайдере (у которого ip1 gate1 dns1)? ведь провайдер (у которого ip3 gate3 dns3) в эти моменты все равно не дефолтный, но это его парализует видимо. а иначе текущий dns может быть не тот, и результат будет нулевым, но может так лучше для общего случая, чем отрицательный вредный результат. а при выходе из ppp0 убрать эти маршруты из таблицы маршрутизации.
"Обычно DNS провайдера доступны только через локалку и при подключении VPN правильный маршрут должен создаваться сам" - тем не менее не всегда и не у всех.
маршрут к vpn-серверу можно для общего случая пустить в локалку - сработает у всех и либо положительный результат, либо нулевой, но не вредный отрицательный. это годится к применению.

[olelukoie]

Я пишу программу, которая должна учесть все ньюансы работы с vpn через pptp в мире, рассмотреть все частные случаи.
Уточню:
У второго провайдера:
ip3
gate3
dns3
что будет если я пущу dns3 не в gate3, а в gate1 временно на период поднятия и работы интерфейса ppp0 на провайдере (у которого ip1 gate1 dns1)? ведь провайдер (у которого ip3 gate3 dns3) в эти моменты все равно не дефолтный, но это его парализует видимо.

Вообще это парализует не только доступ к прову, которому принадлежит этот dns3, но и создаст лаги при доступе к сайтам, если этот самый dns3 окажется первым в списке, покольку он будет недоступен (как я уже сказал, служебные сервера провайдеров вроде dns, vpn и им подобных обычно доступны только через их локальные сети и не доступны через интернет).

а иначе текущий dns может быть не тот, и результат будет нулевым, но может так лучше для общего случая, чем отрицательный вредный результат. а при выходе из ppp0 убрать эти маршруты из таблицы маршрутизации.
"Обычно DNS провайдера доступны только через локалку и при подключении VPN правильный маршрут должен создаваться сам" - тем не менее не всегда и не у всех.
маршрут к vpn-серверу можно для общего случая пустить в локалку - сработает у всех и либо положительный результат, либо нулевой, но не вредный отрицательный. это годится к применению.

"Не всегда и не у всех" что? Маршрут сам не создается? Или DNS доступны и из Интернета (т.е. это публичные DNS-сервера)? В любом случае при подключении VPN доступ к DNS через локалку никуда не денется, так что наличие такого маршрута ничего не ухудшит, а если доступ к DNS через локалку работает быстрее, то только улучшит. Разве нет?
Только опять надо следить за порядком DNS в resolv.conf, иначе доступ к локальным ресурсам может оказаться заблокирован, так как чужой DNS просто ничего не знает о них и не сможет разрешить их имена.

[romkaromka]

Итак, мы пришли к общим заключениям:
1) неплохо имя VPN-сервера прописать в /etc/hosts, сопоставив в нем все айпишки адресу vpn-сервера - в этом случае vpn-сервер будет доступен всегда для пользователей по его имени и станет независим от dns-сервера.
2) неплохо все маршруты до dns-серверов провайдера пустить в локальный шлюз этого провайдера.
3) неплохо адрес vpn-сервера пустить в локальный шлюз (то есть каждое из его айпишек).

В связи с чем, возникают вопросы:
1) если имя VPN-сервера прописать в /etc/hosts, и для каждого из его айпишек будет внесена запись в этот файл, то операционная система будет использовать только одно из этих ип из файла /etc/hosts, остальные ни разу, или случайное значение. Если утверждение о неслучайном и лишь одном ип верно, то достаточно внести в файл /etc/hosts лишь одно ип vpn-сервера, причем любое? Но если это так, то если по этому ип он будет недоступен, а по другим доступен, то бабушка надвое сказала: что лучше независимость vpn-сервера от dns-сервера или зависимость от него.
2) ни в коем случае нельзя пустить в локальный шлюз все dns-сервера из /etc/resolv.conf, но если руководствоваться лишь файлом /etc/resolv.conf, то будет весьма неплохо пустить в локальный шлюз первый по счету dns-сервер согласно их списка в /etc/resolv.conf, причем только один, потому что он на 100% родной (но я не считаю, что это правда, он часто чужой), остальные - под вопросом. но одного такого маршрута до предпочитаемого dns-сервера мало, неплохо было бы и до альтернативного dns-сервера пустить маршрут в локальную сеть (если он существует), но /etc/resolv.conf в решении этой задачи уже бессилен, а учитывая, что сами лезут чужие dns, то файл /etc/resolv.conf и вовсе подлежит исключить из анализа и учитывания информации в нем.
/etc/sysconfig/network-scripts/ifcfg-ethN - здесь можно взять DNS1 и DNS2, а при неудаче поиска в этом файле DNS1 и/или DNS2 - их подлежит взять из файла /var/lib/dhcp/dhclient-ethN.leases, где N - номер сетевой карты, на которой собирается подниматься vpn, так? плюс еще и проверить будет можно: а идущий первым в списке dns-сервер в файле /etc/resolv.conf родной ли, и если не родной, то отказать в поднятии vpn по этой причине - именно этого мандрива и не делает.
3) учитывая, что если утверждение о неслучайном и лишь одном ип верно, если использовать /etc/hosts, то и ип vpn-сервера лишь одно достаточно пустить в локальный шлюз, а если не использовать /etc/hosts, то все эти ип vpn-сервера стоит пустить в локальный шлюз.

[sash-kan]

простите, не осилил всю дискуссию, поэтому, вероятно, повторюсь:

Может ли быть dns1<>dns2?

dns-серверов в resolv.conf может быть несколько. резолвером (из libc) они выбираются в случайном (или последовательном, это не суть) порядке.
ввиду того, что стандартная процедура получения адреса nameserver-а по протоколу dhcp не подразумевает накопления ns-ов в файле resolv.conf, а явно подразумевает его, файла, перезапись, может быть выбран один из вариантов менеджмента двух dhcp-соединений:
1. ничего особого не предпринимаем. какой dhcp-клиент последним отработал (а lease время от времени истекает и dhcp-клиент делает пере-запрос), того и тапки.
2. останавливаемся на фиксированном содержимом resolv.conf. в конфигурациях dhcp-клиентов ставим: «не запрашивать ns».
3. вооружаемся man resolvconf и конф.файлами dhcp-клиентов и рисуем свою собственную, совершенно нестандартную схему формированния /etc/resolv.conf.

небольшой отступ:
само понятие «отдельный ns для отдельного интерфейса» — бессмысленно.
резолверу поступил запрос разрезолвить имя host.zone.
до того, как резолвер получит ip этого хоста, никто и ничто не сможет ему даже намекнуть, через какой из интерфейсов будет лежать маршрут к этому ip-адресу. к тому же разные ns-ы запросто могут вернуть разные ip-адреса для одного и того же имени.

в общем, вы меня поняли. (улыбка)

[romkaromka]

1) sash-kan сказал верную мысль, что если dns2 пустить в gate1, то скорость инета по факту вырастет (к этому выводу мы уже пришли до этого), но может открыться не тот сайт, который бы открылся, если бы dns2 был пущен в gate2.
у моего провайдера ип адреса у dns1 и у dns2 одинаковые и публичны (доступны через внешку), причем публичны по-умолчанию и в таблицу маршрутизации при поднятом vpn не попадают - у меня оба эти варианта маршрутизации работоспособны. поэтому тут идеальной будет опциональность на выбор пользователя.
2) вот и проблема, что resolv.conf перезаписывается, а не накапливает адреса, а в итоге у сети eth0 оказывается dns от сети eth1, а то и вообще может не оказаться никакого dns у eth0.
поэтому resolv.conf просто оставим плыть по течению, не будем использовать инфу из него, а постараемся получить dns из других источников-файлов.

[olelukoie]

ввиду того, что стандартная процедура получения адреса nameserver-а по протоколу dhcp не подразумевает накопления ns-ов в файле resolv.conf, а явно подразумевает его, файла, перезапись...

Разве перезапись, а не дозапись? Я сейчас уже точно не помню, но у меня идет два dns от прова и один от собственного bind, и в resolv.conf фигурируют все три адреса. Причем, поскольку автозагрузка named не включена, адрес локальной машины все время оказывается записанным последним, хотя я переношу его на первое место каждый раз, когда dns прова начинают тупить и я запускаю named. Т.е. адреса dns от последнего поднятого интерфейса дописываются в resolv.conf и при этом указываются первыми, до тех адресов, что там уже были.

[romkaromka]

ввиду того, что стандартная процедура получения адреса nameserver-а по протоколу dhcp не подразумевает накопления ns-ов в файле resolv.conf, а явно подразумевает его, файла, перезапись...

Разве перезапись, а не дозапись? Я сейчас уже точно не помню, но у меня идет два dns от прова и один от собственного bind, и в resolv.conf фигурируют все три адреса. Причем, поскольку автозагрузка named не включена, адрес локальной машины все время оказывается записанным последним, хотя я переношу его на первое место каждый раз, когда dns прова начинают тупить и я запускаю named. Т.е. адреса dns от последнего поднятого интерфейса дописываются в resolv.conf и при этом указываются первыми, до тех адресов, что там уже были.

Если у каждого прова по 2 dns (что является стандартом), то до при дозаписи в файле resolv.conf их было бы 4, но их становится 3. А Вы не замечаете, потому что у Вас 3 было - 3 стало - частный случай.
Т.е. адреса dns от последнего поднятого интерфейса вписываются в resolv.conf и при этом указываются первыми, до тех адресов, что там уже были, а от других dns остается либо ничего, либо лишь малая часть.
Кстати, тут тоже идея появилась неплохая: если на eth0 требуется поднять vpn, то если перед поднятием интерфейса ppp0 перезапустить eth0, то в resolv.conf на первое место попадет уже 100% родное dns, а второе место в resolv.conf останется под вопросом, так как из информации из этого файла неизвестно сколько dns имеется у провайдера.
Как будет обрабатываться файл /etc/hosts, если в нем сделать запись вида?:

Код: Выделить всё

vpn.internet.beeline.ru   85.21.66.200
vpn.internet.beeline.ru   85.21.66.193

Можно ли руководствоваться /var/lib/dhcp/dhclient-ethN.leases или есть еще варианты?

[olelukoie]

ввиду того, что стандартная процедура получения адреса nameserver-а по протоколу dhcp не подразумевает накопления ns-ов в файле resolv.conf, а явно подразумевает его, файла, перезапись...

Разве перезапись, а не дозапись? Я сейчас уже точно не помню, но у меня идет два dns от прова и один от собственного bind, и в resolv.conf фигурируют все три адреса. Причем, поскольку автозагрузка named не включена, адрес локальной машины все время оказывается записанным последним, хотя я переношу его на первое место каждый раз, когда dns прова начинают тупить и я запускаю named. Т.е. адреса dns от последнего поднятого интерфейса дописываются в resolv.conf и при этом указываются первыми, до тех адресов, что там уже были.

Если у каждого прова по 2 dns (что является стандартом), то до при дозаписи в файле resolv.conf их было бы 4, но их становится 3. А Вы не замечаете, потому что у Вас 3 было - 3 стало - частный случай.
Т.е. адреса dns от последнего поднятого интерфейса вписываются в resolv.conf и при этом указываются первыми, до тех адресов, что там уже были, а от других dns остается либо ничего, либо лишь малая часть.

Может быть... Кстати, в директории /etc/resolvconf лежит файл interface-order, может можно с его помощью задать приоритет DNS? По дефолту там стоят имена со звездочками, а если явно прописать eth0, ppp0 и т.д.?

Кстати, тут тоже идея появилась неплохая: если на eth0 требуется поднять vpn, то если перед поднятием интерфейса ppp0 перезапустить eth0, то в resolv.conf на первое место попадет уже 100% родное dns, а второе место в resolv.conf останется под вопросом, так как из информации из этого файла неизвестно сколько dns имеется у провайдера.
Как будет обрабатываться файл /etc/hosts, если в нем сделать запись вида?:

Код: Выделить всё

vpn.internet.beeline.ru   85.21.66.200
vpn.internet.beeline.ru   85.21.66.193

Можно ли руководствоваться /var/lib/dhcp/dhclient-ethN.leases или есть еще варианты?

Если под вариантами имеются в виду адреса VPN-серверов, то их у того же билайна/корбины дофига. Раньше он выдавал их все, в последнее время выдается два или три адреса, но это не значит, что все остальные недоступны. Причем при смене настроек на стороне прова (например, пул расширится, или сделают новый сегмент и перераспределят адреса, что уже бывало в той же корбине) эти адреса могут стать другими (но из того же пула).
С другой стороны я вот больше пользуюсь L2TP (и стабильнее, и быстрее работает), так я прописал себе адрес VPN, который dns мне никогда не давал, а о его существовании я узнал на корбиновском форуме в одной из тем с логами и трассировками. И работает этот "брас" гораздо быстрее тех, что выдаются по dns (даже пинг до него меньше 1 мс, а до выдаваемых по dns - не менее 1.5). С другой стороны из трех выдаваемых мне dns адресов два (.251 и .255) приводят к зависанию xl2tpd/pppd. Так что записывать или не записывать эти адреса в /etc/hosts - вопрос неоднозначный.

А вообще узнать адреса vpn гораздо проще командой host vpn.internet.beeline.ru. И выполнять ее до подключения vpn, естественно. Главное, чтобы dns корбины был в это время доступен, так как чужой не выдаст ничего или выдаст совсем не те адреса. Вот я сейчас на работе:

Код: Выделить всё

$ host vpn.corbina.ru
vpn.corbina.ru has address 78.107.1.51
vpn.corbina.ru has address 78.107.1.52
vpn.corbina.ru has address 85.21.0.66
vpn.corbina.ru has address 78.107.1.49
vpn.corbina.ru has address 78.107.1.50
$ host vpn.corbina.net
vpn.corbina.net has address 78.107.1.51
vpn.corbina.net has address 78.107.1.52
vpn.corbina.net has address 85.21.0.66
vpn.corbina.net has address 78.107.1.49
vpn.corbina.net has address 78.107.1.50
$ host tp.corbina.net
tp.corbina.net has address 85.21.0.251
tp.corbina.net has address 85.21.0.253
tp.corbina.net has address 85.21.0.255
$ host tp.corbina.ru
tp.corbina.ru has address 85.21.0.251
tp.corbina.ru has address 85.21.0.253
tp.corbina.ru has address 85.21.0.255
$ host tp.internet.beeline.ru
Host tp.internet.beeline.ru not found: 3(NXDOMAIN)
$ host vpn.internet.beeline.ru
Host vpn.internet.beeline.ru not found: 3(NXDOMAIN)

[romkaromka]

1) /etc/sysconfig/network-scripts/ifcfg-ethN - здесь можно взять DNS1 и DNS2, а при неудаче поиска в этом файле DNS1 и/или DNS2 - их подлежит взять из файла /var/lib/dhcp/dhclient-ethN.leases, где N - номер сетевой карты, на которой собирается подниматься vpn, так? кроме DNS нас в этих файлах не интересует больше ничего.
стоит задача найти такой алгоритм, который работал бы у всех, причем с настройками операционки по-умолчанию или с минимальным в нее вмешательством.

2) Как будет обрабатываться файл /etc/hosts, если в нем 2 записи с одним именем и с разными айпишками (см. пример выше)?
Кажется, что будет использоваться только первое попавшееся 85.21.66.200, а 85.21.66.193 не будет использоваться никогда, или нет?

3) host хорош, но по-умолчанию пакет bind-utils не установлен, поэтому отпадает, но не совсем.
Я не имею права сделать так, чтобы для установки соединения с интернетом необходимо было скачать из интернета зависимости, ведь связи еще нет.
Однако, был бы весьма полезен скрипт, выполняющий те же функции, что и host из bind-utils, а именно: определение списка ip-адресов по имени. Где взять его?, все переискал. Опять же аналог host нужен лишь в случае если /etc/host не будет обрабатываться по лишь одной записи, а если /etc/host обрабатывается лишь по одной записи, к примеру 85.21.66.200 и всегда пропускает 85.21.66.193, то одну запись об ип vpn-сервера я и через ping могу определить и в /etc/host положить, то есть штатными средствами операционки.

[olelukoie]

3) host хорош, но по-умолчанию пакет bind-utils не установлен, поэтому отпадает, но не совсем.
Я не имею права сделать так, чтобы для установки соединения с интернетом необходимо было скачать из интернета зависимости, ведь связи еще нет.

А кто сказал, что bind-utils по умолчанию не ставится? В любом случае он есть на дисках версий Free (DVD) и Free Dual (CD), так что даже если он по дефолту не поставился, его можно поставить с диска. Вот на дисках One его, похоже, действительно нет.

И потом host - это не скрипт, а бинарная прога, причем очень не хилая по размеру: бинарник, слинкованный динамически, весит более полутора метров. И зависит он не только от libc, но и от libxml2, zlib, libcrypto (openssl) и др, т.е. умеет работать с xml (правда зачем - не понятно), поддерживает сжатие и шифрование. Так что воспроизвести его функциональность будет, имхо, задачей нетривиальной. Проще уж включить его исходный код в состав проги, которую Вы пишете.

[romkaromka]

Да, на дисках One bind-utils нет. Вы правильно поняли: нужен лишь скрипт, который по имени выдаст список айпишек, а алгоритм можно взять из программы host, хотя и не обязательно, остальная функциональность программы host ни к чему.
Кто сможет такой скрипт состряпать?

[olelukoie]

Да, на дисках One bind-utils нет. Вы правильно поняли: нужен лишь скрипт, который по имени выдаст список айпишек, а алгоритм можно взять из программы host, хотя и не обязательно, остальная функциональность программы host ни к чему.
Кто сможет такой скрипт состряпать?

Код: Выделить всё

$ ping tp.corbina.net -c 1 | grep PING | awk '{print $3}' | sed 's/(//' | sed 's/)//'
85.21.0.253

Не?

[romkaromka]

ping только одно ip умеет возвращать, но их может быть несколько, у меня вот их 2.
с другой стороны, можно научить конфигуратор vpnpptp заносить в файл /etc/hosts ip vpn-сервера, полученный от ping, если этот ip еще не занесен в /etc/hosts.
в итоге при каждом переконфигурировании соединения список ip в /etc/hosts будет расти, но с течением времени соединение может быть неработоспособным, так как /etc/hosts будет накапливать неработоспособные ip vpn-сервера.
или, можно научить конфигуратор vpnpptp заносить в файл /etc/hosts ip vpn-сервера, полученный от ping, удаляя предыдущие записи об этом vpn-сервере из /etc/hosts - в итоге первый отозвавшийся и станет главным до тех пор, пока не отзовется другой при переконфигурировании соединения.
но все же аналог программы host был бы идеальным решением.
кто знает ответы dns, vpn и mandriva ?

[sash-kan]

1) /etc/sysconfig/network-scripts/ifcfg-ethN - здесь можно взять DNS1 и DNS2, а при неудаче поиска в этом файле DNS1 и/или DNS2 - их подлежит взять из файла /var/lib/dhcp/dhclient-ethN.leases, где N - номер сетевой карты, на которой собирается подниматься vpn, так? кроме DNS нас в этих файлах не интересует больше ничего.
стоит задача найти такой алгоритм, который работал бы у всех, причем с настройками операционки по-умолчанию или с минимальным в нее вмешательством.

2) Как будет обрабатываться файл /etc/hosts, если в нем 2 записи с одним именем и с разными айпишками (см. пример выше)?
Кажется, что будет использоваться только первое попавшееся 85.21.66.200, а 85.21.66.193 не будет использоваться никогда, или нет?

3) host хорош, но по-умолчанию пакет bind-utils не установлен, поэтому отпадает, но не совсем.
Я не имею права сделать так, чтобы для установки соединения с интернетом необходимо было скачать из интернета зависимости, ведь связи еще нет.
Однако, был бы весьма полезен скрипт, выполняющий те же функции, что и host из bind-utils, а именно: определение списка ip-адресов по имени. Где взять его?, все переискал. Опять же аналог host нужен лишь в случае если /etc/host не будет обрабатываться по лишь одной записи, а если /etc/host обрабатывается лишь по одной записи, к примеру 85.21.66.200 и всегда пропускает 85.21.66.193, то одну запись об ип vpn-сервера я и через ping могу определить и в /etc/host положить, то есть штатными средствами операционки.

1. а вариант с универсальными ns-ами вам не подходит? (те же гугловские 8.8.8.8 и 8.8.4.4).
2. afaik, резолвером из libc будет взято первое совпадение. эксперимент подтверждает.
3. nslookup?

romkaromka
>ping только одно ip умеет возвращать

ping возвращает ответы на посланные icmp-пакеты.
для преобразования имён в ip он использует всё тот же библиотечный резолвер.

[olelukoie]

1. а вариант с универсальными ns-ами вам не подходит? (те же гугловские 8.8.8.8 и 8.8.4.4).

Вряд ли, поскольку универсальные ns-ы а) ничего не знают о локальных ресурсах провайдера и не смогут резолвить их имена и б) доступны только после подключения vpn.

3. nslookup?

nslookup тоже входит в bind-utils и поэтому тоже отпадает:

Код: Выделить всё

$ rpm -qf `which nslookup`
bind-utils-9.6.1-4.2mdv2010.0

[romkaromka]

Ну раз файл /etc/hosts обрабатывается по первому совпадению, то достаточно будет возможности ping - ip адрес vpn-сервера будет получен (ну или не получен) и занесен в /etc/hosts, а при переконфигурировании vpnpptp - он будет вновь определен через ping и в файле /etc/hosts заменен. Этим методом будет обеспечиваться независимость vpn-сервера от dns-сервера. В этой части разобрались.
Вопрос в части как пускать dns в шлюз локальной сети или через внешку тоже решен - пускать на выбор пользователя.
Осталось решить вопросы:
1) где брать DNS в случае если они предоставляются по протоколу DHCP, из какого файла(ов),
2) стоит ли их все пускать в шлюз локальной сети,
3) какой командой определять текущее дефолтное, в данный момент времени используемое dns или можно в этом случае руководствоваться первой строчкой в файле /etc/resolv.conf.

Также может оказаться полезной мысль - в случае падения родных dns (когда они перестанут отзываться на ping) уже при поднятом vpn переключаться на гугловские.