В блоге « Служба tinyurl для вашего домена » объясняется, как настроить службу ShortName для вашего домена с помощью Служб Google. Например, если ваш домен example.comи вы используете Службы Google, вы можете настроить его так, чтобы http://go.example.comэто была личная служба ShortName вашего предприятия.

ПРИМЕЧАНИЕ. Речь идет не о создании службы "tinyurl" для использования в мире. Это для предприятия.

Полезно иметь службу коротких имен, которую могут использовать только ваши пользователи, чтобы вы могли создавать ссылки на внутренние страницы. Вместо того, чтобы рассказывать людям длинный трудный URL, вы можете сказать: «Меню ланча сегодня на http://go.example.com/lunch ». В сообщении блога описаны некоторые преимущества, которые дает людям возможность создавать собственные ссылки. (Самое главное: им не нужно беспокоить вас, чтобы создать новую ссылку!)

Проблема

Проблема с системой в том, что URL все еще довольно длинный. Люди предпочитают набирать «go / lunch» в своем веб-браузере и заставить его работать. К сожалению, Google Apps не могут это поддерживать из-за технической сложности работы протокола HTTP. В заголовке «Host:» в HTTP 1.1 указан домен, который пользователь ввел в свой веб-браузер, а не полное доменное имя . Другими словами, когда Google Apps получает HTTP-запрос на « http: // go / lunch », веб-сервер получает «go» в качестве имени хоста. Поскольку Службы Google предоставляют эту услугу для многих доменов, она не может определить, хотите ли вы go.example.comили go.some-other-example.com.

В результате пользователям приходится каждый раз вводить «go.example.com/lunch», что намного дольше, чем «go / lunch».

Решение

Google может решить эту проблему, используя веб-куки или другую схему. Ни один из которых не особенно чистый или легкий. Пока они этого не сделают, вы можете решить проблему, настроив собственный компьютер, который принимает запросы как «go» и перенаправляет их.

Сервер принимает HTTP-запросы для сайта под названием «go» и перенаправляет запрос на go.example.com. Затем вы создаете правильные записи DNS, чтобы они работали, и переключали настройки DHCP, чтобы ваши ноутбуки / рабочие станции работали правильно.

Смысл этого документа о сбое сервера состоит в том, чтобы объяснить процесс, а затем привести примеры конфигурации, которые помогут вам сделать это для вашего сайта. Поскольку у меня нет доступа или знаний о каждой операционной системе в мире, я делаю это "вики-сообществом", чтобы люди могли заполнять фрагменты конфигурации так, как они работают на них. Я поместил «TODO» в область, которая особенно нуждается в улучшении.

Детали

В этом примере мы будем использовать «example.com» в качестве домена.

Шаг 1. Настройте службу Служб Google обычным способом.

Настройте службу go.example.comкак обычно. Проверьте это и убедитесь, что URL-адрес, как http://go.example.com/fooработает. Не продолжайте, если это не завершено. Это все равно что пытаться отремонтировать свою машину до того, как вы ее приобретете.

Шаг 2: Выберите ваше имя хоста перенаправителя

Если вы используете службу коротких имен go.example.com, в идеале вы должны указать имя вашего перенаправителя go.example.com. К сожалению, физика не позволяет двум телам находиться в одном и том же месте одновременно, а DNS подчиняется законам физики.

Хитрость заключается в том, чтобы перенаправитель имел то же имя хоста, что и служба ShortName, но в другом домене. Так , например, go.corp.example.com, go.ext.google.com, или go.this-is-different.example.com.

Крупные компании обычно имеют внутренний поддомен, который не подвержен влиянию внешнего мира. Обычно внутренние хосты есть INSIDEHOST.corp.google.com. Вот куда вы положили редиректор.

Некоторые компании выделяют субдомен, заполненный CNAME, указывающими на сервисы, к которым следует обращаться как внутри, так и за пределами компании. Таким образом, есть один поддомен, который нужно поместить в DNS-путь поиска людей. (Люди Unix могут думать об этом как о наличии /usr/local/binподкаталога, заполненного символическими ссылками) Традиционно этот поддомен есть ext.example.com. В этой подобласти являются CNAMEs , как mail.ext.example.com, calendar.ext.example.com, vpn.ext.example.comи так далее.)

Предупреждение. Добавление еще одного элемента в путь поиска DNS - это еще один способ замедлить работу компьютеров. Выполнение дополнительного DNS-запроса КАЖДЫЙ ВРЕМЯ идет медленно, а работа в Интернете будет заметно медленнее. Гораздо лучше добавить этот перенаправитель в поддомен, который уже находится в пути поиска DNS вашего компьютера, даже если это означает добавление CNAME в несколько поддоменов. Например, если ваши внутренние машины и машины, подключенные к вашей VPN, уже имеют corp.example.comсвой путь поиска, добавьте туда CNAME. Если вы хотите, чтобы внешние машины, не подключенные к VPN, могли иметь доступ к перенаправителю, было бы странно вводить жесткий код corp.example.comв их путь поиска, если это поддомен для машин, к которым никогда не обращались извне. В этом случае другой CNAME может быть добавлен во внешний поддомен (например,ext.example.com) указать на редиректор. Обновите конфигурацию веб-сервера для поддержки обоих.

Для этого примера предположим, что вы выбрали перенаправитель go.ext.example.com. Машину можно называть как угодно, мы сделаем все возможное в DNS и настройке веб-сервера.

Шаг 3. Планирование перенаправителя

Веб-сервер, который вы собираетесь настроить, может находиться на существующем веб-сервере или на новом, созданном специально для этой цели. Ключевым моментом является то, что машина должна быть доступна из любого места, где вы хотите, чтобы служба ShortName работала: внутри компании, вне компании, когда пользователь подключен через VPN. (Вы можете отказаться от этой работы из-за пределов компании по соображениям безопасности. Вы также можете по соображениям безопасности настроить один компьютер изнутри, а другой - снаружи.)

Примечание. Для этого вам не нужно настраивать новый веб-сервер. Вы можете добавить это на уже существующий веб-сервер, если конфигурация не существует.

Примечание: это может быть довольно сложно. Возможно, вы захотите сосредоточиться на том, чтобы это работало в самом простом случае, а затем, после того, как оно будет работать и протестировано, заставьте его работать в других ситуациях. В частности, заставить его работать в следующем порядке: 1. рабочие станции / ноутбуки внутри компании 2. ТОГДА машины, подключенные через VPN, затем машины вне компании (например, в интернет-кафе). 3. ТОГДА машины вне сети, без VPN up 4. ТОГДА проверяют это для других операционных систем

В этом примере мы предполагаем, что существует веб-сервер, доступный по тому же IP-адресу, независимо от того, находитесь ли вы в компании или за ее пределами.

В нашем примере «go. Corp .example.com» это означает, что «go» находится в поддомене, доступном только для инсайдеров, и требует VPN для использования службы ShortName. Поскольку Службы Google обычно настроены на работу без VPN (поскольку весь доступ осуществляется по протоколу HTTPS), это является неоптимальным.

В нашем «идти. Внутр например .example.com», это означает , что субдомен доступен как внутри , так и вне компании, а также Aзаписи точек на внешний IP - адрес.

Шаг 4. Добавьте записи DNS для вашего перенаправителя

Вот необходимые записи DNS:

go.example.com.                IN CNAME ghs.google.com.
go.ext.example.com.            IN A 64.32.179.5
go-redirector.example.com  IN A 64.32.179.5

Первая запись DNS (go.example.com) должна существовать уже как часть шага 1.

Второй DNS записи (идти. Внутр .example.com) является Aзапись , указывающая на IP - адрес нового веб - сервера вы настраиваете.

Третья запись DNS (go-redirector) предназначена для помощи при отладке.

Шаг 5: Настройте веб-сервер

Добавьте перенаправление на веб-сервер. (Предполагается, что веб-сервер уже установлен и работает).

Вот фрагмент конфигурации Apache:

<VirtualHost *:80>
        ServerName go-redirector.example.com
        ServerAlias go, go.ext, go.ext.example
        RewriteEngine on
        RewriteRule ^(.*)$ http://go.example.com$1 [R=permanent]
</VirtualHost>

Как это проверить. http://go-redirector.example.comдолжен работать на этом этапе.

Не продолжайте, пока этот тест не сработает. Шаги малыша.

Шаг 6: Настройте клиентский путь поиска DNS

Теперь мы собираемся настроить компьютеры (все, что работает с веб-браузером) так, чтобы путь поиска DNS включал «ext.example.com»

На вашем DHCP-сервере и VPN-сервере отправьте путь поиска DNS, который:

corp.example.com.

(поддомен с узлом перенаправления, после которого следует «.»)

В качестве альтернативы вы можете использовать путь поиска, например:

corp.example.com example.com.

Однако это добавит дополнительный поиск DNS для КАЖДОЙ чертовой веб-страницы, на которую мы заходим. Поскольку они будут выходить из строя в 99% случаев, это только замедлит работу в Интернете.

На рабочих станциях и ноутбуках необходимо убедиться, что поддомен включен в их путь поиска DNS. Таким образом, когда пользователь вводит «go», программа находит его в домене.

Мы хотим настроить путь поиска машины так, чтобы он включал этот поддомен каждый раз, когда путь поиска может быть установлен:

Первоначально путь поиска DNS не мог быть установлен через DHCP. Это новая функция, которую поддерживают не все клиенты DHCP. Даже клиенты DHCP, которые поддерживают его, должны быть изменены, потому что, когда ноутбук находится (например) в интернет-кафе, он общается с сервером DHCP, который вы не контролируете. Когда ноутбук использует VPN, программное обеспечение клиента VPN фактически не использует DHCP, но обычно сервер VPN передает параметры, которые обычно получают от сервера DHCP.

Поэтому вы хотите установить путь поиска DNS во всех этих местах:

• DHCP-сервер должен отправить параметры пути поиска DNS
• Статически настроенные машины должны иметь свой путь поиска DNS
• Клиенты, использующие DHCP, должны быть настроены на предварительное ожидание corp.example.comдомена в пути поиска, если DHCP-сервер его еще не включил.

Ниже приведены инструкции о том, как это сделать на различных DHCP-серверах и в операционных системах.

Настройка DHCP-серверов для включения пути поиска DNS:

1. Windows DHCP инструкции

СДЕЛАТЬ

2. ISC DHCP инструкции

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

option domain-name "corp.example.com";

Если клиенты поддерживают RFC 3397 для предоставления пути поиска, то вы можете сделать это, но это неудобно, поскольку нет встроенной поддержки типа данных, который представляет собой последовательность узлов DNS, каждый из которых закодирован как метки с префиксом длины, как в DNS. Невозможно записать значения параметра, определенного как массив записей, где запись содержит массив другой записи, поэтому вы можете использовать строку данных для ручного кодирования.

option dns-search-domains code 119 = string;
option dns-search-domains concat(
    encode-int(4,1), "corp", encode-int(7,1), "example", encode-int(3,1), "com", encode-int(0,1),
    encode-int(7,1), "example", encode-int(3,1), "com", encode-int(0,1)
    );

который должен (не проверен) создать список поиска из двух элементов.

3. DHCP инструкции dnsmasq

СДЕЛАТЬ

Конфигурирование статически настроенных машин:

1. Windows

СДЕЛАТЬ

2. Linux / Unix

Отредактируйте /etc/resolv.confи убедитесь, что (1) «домен corp.example.com» является первой строкой, (2) добавьте / отредактируйте строку «поиск», чтобы включить corp.example.comдомен, (3) добавьте строку «options ndotes: 2» в уменьшите нагрузку на ваши DNS-серверы.

domain corp.example.com
search corp.example.com exmaple.com
options ndots:2

Настройка DHCP-клиентов для работы на других DHCP-серверах

Заполнить TODO для Windows, Linux и т. Д.

Шаг 7: Тест, тест, тест!

Теперь пользователи должны иметь возможность указать:

http: // go / foo http: //go.example/foo http://go.example.com/foo

Фактически, в качестве теста на достоверность вы захотите проверить эти URL-адреса во всех ситуациях:

( each OS you support ) * ( internal LAN / at an Internet cafe / while on the VPN )

Шаг 8: Другие советы

И, наконец, один совет: даже если вы отлично справились с этой задачей, вы все равно рискуете, что http://go/fooссылка не будет работать, когда человек пытается набрать ее на компьютере, который вы не настроили для принудительного поиска DNS путь для включения вашего домена. Вы должны, следовательно, публиковать ссылки , используя полный URL: http://go.example.com/foo; и потратьте время, чтобы обучить отдел по связям с общественностью вашей компании и других, чтобы всегда указывать это таким образом.

Или, по крайней мере, закодировать их в HTML, чтобы в тексте ссылки было видно «go», но фактический HREF переходит в полное доменное имя:

<a href="http://go.example.com/lunch">go/lunch</a>

Научить людей в отделе по связям с общественностью сделать это может быть сложно. Возможно, вы просто захотите сказать им, что они должны использовать длинную версию ( go.example.com) во всем, что они пишут, потому что короткий «go / lunch» работает только случайно.

Шаг 8: HTTPS

TODO: выяснить, как работать с HTTPS (получить сертификаты будет очень сложно, если не невозможно).

Этот вопрос должен быть помечен как «ответ» так или иначе. Таким образом, /server//unanspted URL останется правильным. Пожалуйста (отправьте и) примите «ответ» на этот вопрос. Благодарность!

Мой «ответ» заключается в том, что создание (или установка) службы сокращения ссылок очень просто, и вместо того, чтобы перепрыгивать через все вышеописанные циклы, просто установите локальный сокращатель ссылок на веб-сервере, который отвечает «go». example.com "и убедитесь, что ваш DNS отвечает на запрос example.com. Таким образом, вы не пропускаете внутренние URL в мир. (Возможно, я упускаю суть.)

Альтернативы:

• Для очень маленькой компании или рабочей группы попросите всех своих любимых закладок и найдите место, чтобы разместить их на главной странице интрасети.

• Кроме того, разверните Интранет для вашей небольшой компании или группы в виде вики с удобным списком общих горячих ссылок, которые помогут людям добраться туда, куда они, вероятно, захотят пойти.

Ура -дэнни