Запись в блоге "Сервис «tinyurl» для вашего домена" объясняет, как настроить службу ShortName для вашего домена с помощью Google Apps. Например, если ваш домен example.comи вы используете Google Apps, вы можете настроить его так, чтобы это 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 Apps предоставляет эту услугу для многих доменов, он не может определить, хотите ли вы go.example.comили go.some-other-example.com.
В результате пользователям приходится каждый раз вводить «go.example.com/lunch», что намного длиннее, чем «go/lunch».
Решение
Google может решить эту проблему, используя веб-куки или какую-то другую схему. Ни одна из них не является особенно чистой или простой. Пока они не станут такими, вы можете решить проблему, настроив собственную машину, которая принимает запросы как «go» и перенаправляет их.
Сервер принимает HTTP-запросы для сайта под названием «go» и перенаправляет запрос на go.example.com. Затем вы создаете правильные записи DNS, чтобы все работало, и настраиваете конфигурации DHCP, чтобы ваши ноутбуки/рабочие станции работали правильно.
Цель этого документа Server Fault — объяснить процесс, а затем привести примеры конфигурации, которые помогут вам сделать это для вашего сайта. Поскольку у меня нет доступа или знаний о каждой операционной системе в мире, я делаю это «вики сообщества», чтобы люди могли заполнять фрагменты конфигурации по мере того, как они будут работать у них. Я поместил «TODO» в область, которая особенно нуждается в улучшении.
Детали
В этом примере мы будем использовать в качестве домена «example.com».
Шаг 1: Настройте службу Google Apps обычным способом.
Настройте службу 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 searchpath людей. (Пользователи Unix могут думать об этом как о /usr/local/binподкаталоге, полном символических ссылок.) Традиционно этот поддомен — ext.example.com. В этом поддомене есть CNAME, такие как 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 4. ЗАТЕМ проверить это для других операционных систем
В этом примере мы предположим, что существует веб-сервер, доступный по одному и тому же IP-адресу независимо от того, находитесь ли вы внутри компании или за ее пределами.
В нашем «гоу.корпорацияВ примере «.example.com» это означает, что «go» находится в поддомене, который доступен только для инсайдеров и требует VPN для использования службы ShortName. Поскольку Google Apps обычно настроены на работу без 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 (go.доб..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:
- Инструкции DHCP для Windows
ДЕЛАТЬ
- Инструкции 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)
);
который должен (не проверено) сгенерировать список поиска из двух элементов.
- dnsmasq инструкции DHCP
ДЕЛАТЬ
Настройка статически сконфигурированных машин:
- Окна
ДЕЛАТЬ
- Линукс/Юникс
Отредактируйте /etc/resolv.confи убедитесь, что (1) «domain corp.example.com» является первой строкой, (2) добавьте/отредактируйте строку «search», включив в нее домен 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; и уделить время обучению PR-отдела вашей компании и других всегда указывать его именно так.
Или, по крайней мере, закодируйте их в HTML так, чтобы «go» было видно в тексте ссылки, но фактический HREF ведет к полному доменному имени:
<a href="http://go.example.com/lunch">go/lunch</a>
Научить этому людей в отделе по связям с общественностью может быть сложно. Вы можете просто сказать им, что они должны использовать длинную версию ( go.example.com) во всем, что они пишут, потому что короткая "go/lunch" срабатывает только случайно.
Шаг 8: HTTPS-протокол
TODO: Разработать, как работать с HTTPS (сертификации будет очень сложно, если не невозможно, получить).
решение1
Этот вопрос следует пометить как «отвеченный» тем или иным способом. Таким образом,https://serverfault.com/unansweredURL останется корректным. Пожалуйста (опубликуйте и) примите "ответ" на этот вопрос. Спасибо!
Мой «ответ» будет заключаться в том, что создание (или установка) сервиса сокращения ссылок — это просто, и вместо того, чтобы прыгать через все вышеперечисленные обручи, просто настройте локальный сокращатель ссылок на веб-сервере, который отвечает на «go.example.com», и убедитесь, что ваш DNS отвечает на search example.com. Таким образом, вы не допустите утечки внутренних URL-адресов в мир. (Возможно, я не понимаю сути.)
Альтернативы:
Если вы работаете в очень небольшой компании или рабочей группе, попросите каждого из вас поделиться своими любимыми закладками и найдите место для их размещения на главной странице интрасети.
В качестве альтернативы можно развернуть Интранет для вашей небольшой компании или группы в виде вики с удобным списком общих ссылок, которые помогут людям попасть туда, куда они, скорее всего, захотят попасть.
Привет, -Дэнни