November 2019

S M T W T F S
      12
34 5 678 9
10111213141516
17181920212223
24252627282930

Style Credit

Expand Cut Tags

No cut tags
Thursday, July 23rd, 2009 11:37 am

О внутривенном применении коаксила. Вообще-то, он предназначен для приема внутрь в таблетках.

и о последствиях  такого применения в картинках. Слабонервным, впечатлительным, беременным и несовершеннолетним не смотреть!!! Там правда страшно.

Оригинал этой записи в личном блоге.

Tuesday, October 13th, 2009 07:41 pm (UTC)
Если у контроллера домена два интерфейса, а один смотрит например в другую (внешнюю) сеть, в список адресов домена в днс опубликуются автоматически (и это я не знаю где отключить) оба адреса. И получается классный цирк, клиенты то видят контроллер, потому что им dns возвращает адрес своей сети, то не видят. Если сетевых карт две, то во второй карточке в качестве днс-а предлагается записать собственный внешний адрес.
Tuesday, October 13th, 2009 08:05 pm (UTC)
у меня более простой вопрос - про клиентскую машину с двумя соединениями
Wednesday, October 14th, 2009 05:27 am (UTC)
очень просто решить - снять галку "register this connection in DNS" на внешнем адаптере.

порядок предпочтения физических адаптеров тоже настраивается.
Wednesday, October 14th, 2009 05:57 am (UTC)
на контроллере домена эта галочка не поможет.

Wednesday, October 14th, 2009 06:27 am (UTC)
Сейчас не могу проверить - нет таких DC в доступности. Но раньше точно помогало, когда отвязывал от внешней сетевушки все сервисы, кроме TCP, и настраивал порядок интерфейсов.

А вообще - multihomed DC меня раздражали ещё с 2000й, поэтому по возможности избавляюсь от таких конфигураций.
Wednesday, October 14th, 2009 06:59 am (UTC)
>А вообще - multihomed DC меня раздражали ещё с 2000й
нет иногда другого выхода

Я не сам это все придумал http://admin.vlady.ru/w2k-dns.htm


Если на контроллере с работающим DNS установлено более одного сетевого интерфейса (внимание! это плохая практика! не стОит делать любой контроллер домена многодомным/multihomed по многим причинам!), то на всех "внутренних" интерфейсах надо прописать DNSы как указано выше, а на всех "внешних" (глядящих "наружу" вашей локальной сети, например, на провайдера) интерфейсах надо указать в качестве "первого DNS" только IP этого же самого интерфейса, т.е. "самого себя" (но ни в коем случае не 127.0.0.1!), а "вторым DNSом" не указывать ничего.
Wednesday, October 14th, 2009 09:10 am (UTC)
про шутку со 127.0.0.1 я уже почитал, он тогда может и клиентам по DHCP раздавать этот же 127.0.0.1 в качестве DNSа :)

а вот что контроллер домена в результате не стоит делать multihomed - это IMHO очень неправильно с точки зрения надёжности
Wednesday, October 14th, 2009 09:54 am (UTC)
>а вот что контроллер домена в результате не стоит делать multihomed - это IMHO очень неправильно с точки зрения надёжности

Ну вот пришлось. Причем второй интерфейс смотрит не в интернет, а в сеть мегафона, и фигачит туда смс-ки клиентам банка.
Wednesday, October 14th, 2009 09:11 am (UTC)
а как насчет порядка предпочтения "логических" адаптеров - ppp, vpn и прочие туннели?
Thursday, October 15th, 2009 10:36 am (UTC)
Вроде бы (!) пофигу на адаптеры, смотрится через таблицу маршрутизации, а там от метрики, дальше понятно.
Но не поручусь.
Thursday, October 15th, 2009 10:40 am (UTC)
ну вот в инструкции английским по белому написано про preferred adapter.

а практика показывает, что при наличии физического соединения с задранной метрикой и VPNного с маленькой метрикой ответ используется от DNSа на физическом соединении. может, конечно, это оттого, VPNный DNS не успел ответить за первую секунду, и на второй итерации ответ от локального DNSа пришел раньше..
Tuesday, October 13th, 2009 07:57 pm (UTC)
можно на VPN-соединении вручную прописать локальный DNS вместо провайдерского, получаемого по DHCP.
Tuesday, October 13th, 2009 08:03 pm (UTC)
можно, конечно, но в данном случае VPNный DNS даже нужнее, чем локальный. и я спрашивал не о том, что поменать, а о том, как оно работает в случае с двумя DNSами
Tuesday, October 13th, 2009 09:22 pm (UTC)
У меня машина штатно в VPN сидит. Основной DNS где-то за VPN'ом. Ближайший - провайдерский. До провайдерского дело доходит только когда VPN недоступен, ну может еще пару раз в каких-то пограничных ситуациях я наблюдал, как дело до провайдера доходило, но никакой уверенности, что в это время VPN был жив.
Tuesday, October 13th, 2009 09:41 pm (UTC)
а как ты определяешь, к какому DNSу запросы идут?
Tuesday, October 13th, 2009 09:46 pm (UTC)
Внутренние сайты внешний DNS не срезолвит, при этом у него есть мудацкая привычка редиректить на свой хомяк все, что не резолвится.

Так, что как только внутренний DNS отвалится я тут же увижу хомяк провайдера на первом же запросе к внутреннему сайту.
Tuesday, October 13th, 2009 08:32 pm (UTC)
Если судить по этой статье (http://support.microsoft.com/kb/942440), то
However, the DNS Client service first looks for a route that can be used to connect to the DNS server on the VPN adapter. Then, the DNS Client service can determine whether the DNS server on the VPN adapter can be reached.
Tuesday, October 13th, 2009 08:58 pm (UTC)
это немножко не о том. из статьи следует, что DNS client не тупо ломится во все DNSы, а проверяет роутинг на предмет доступности этих серверов. но в случае, когда оба сервера доступны, всё равно непонятно, как они будут использоваться
Tuesday, October 13th, 2009 09:35 pm (UTC)
Ну вот ещё одна статейка нашлась: Multiple Interfaces on Windows draft-montenegro-mif-multihoming-00 (http://tools.ietf.org/html/draft-montenegro-mif-multihoming-00)
В 6-м разделе написанно:
1) Посылает запрос первому DNS-у на предпочтительном интерфейсе и ждёт 1 сек.
2) Посылает запрос 1-му DNS-у на всех интерфейсах и ждёт 2 сек.
3,4,5) Посылает запрос всем DNS-ам на всех интерфейсах и 2, 4, 8 секунд.

Что он выбирает в случаях 2-8 осталось не ясным, но из логики этой схемы следует что тот ответ, который придет первым.


Tuesday, October 13th, 2009 09:59 pm (UTC)
спасибо, это уже ближе. осталось понять, что есть предпочтительный интерфейс..
Tuesday, October 13th, 2009 10:30 pm (UTC)
тот, где default route?
других вариантов не вижу
Wednesday, October 14th, 2009 07:04 am (UTC)
он на обоих. в отличие от юниксов, windows умеет использовать метрики маршрутов. поэтому при установке VPN-соединения старый default route не убирается совсем, а ему просто завышают метрику.
Wednesday, October 14th, 2009 07:28 am (UTC)
Тогда тот из default'ов, у кого метрика меньше.
Tuesday, October 13th, 2009 10:10 pm (UTC)
тут вот более полная схема есть: http://technet.microsoft.com/en-us/library/cc772774%28WS.10%29.aspx
но вот кто такой preferred adapter..
Wednesday, October 14th, 2009 08:14 am (UTC)
должен ролять "Connection-specific DNS Suffix"
а preferred adapter может имеется ввид то что в "adapters and binding"? там же есть стрелки вверх-вниз.