Повідомлення в блозі " Служба" tinyurl "для вашого домену " пояснює, як налаштувати службу ShortName для вашого домену за допомогою Google Apps. Наприклад, якщо ваш домен є, example.comа ви використовуєте Google Apps, ви можете налаштувати його так, щоб http://go.example.comце була персональна послуга вашої компанії ShortName.
ПРИМІТКА. Йдеться не про створення служби "tinyurl" для використання у світі. Це для підприємства.
Корисно мати службу коротких імен, яку можуть використовувати лише ваші користувачі, щоб ви могли створювати посилання на внутрішні сторінки. Замість того, щоб розповідати людям довгу складну URL-адресу, ви можете сказати: "Сьогоднішнє меню обід знаходиться за адресою http://go.example.com/lunch ". Повідомлення в блозі документує деякі переваги надання можливості людям налаштовувати власні посилання. (Найголовніше: вони не повинні турбувати ВАС, щоб створити нове посилання!)
Проблема
Проблема системи полягає в тому, що URL все ще досить довгий. Люди вважають за краще ввести "іти / обід" у свій веб-переглядач і нехай це працює. На жаль, Google Apps не можуть підтримати це через технічну характеристику роботи протоколу HTTP. Заголовок "Хост:" в HTTP 1.1 перераховує домен, який користувач ввів у свій веб-браузер, а не FQDN . Іншими словами, коли Google Apps отримує HTTP-запит на " http: // go / lunch ", веб-сервер отримує "go" як ім'я хоста. Оскільки додатки Google надає цю послугу для багатьох доменів, він не може сказати , якщо ви хочете go.example.comабо go.some-other-example.com.
У результаті користувачі повинні кожен раз набирати "go.example.com/lunch", що набагато довше, ніж "go / обед".
Рішення
Google може вирішити це за допомогою веб-файлів cookie чи іншої схеми. Жоден з них не є особливо чистим і легким. Поки ви не зможете вирішити проблему, встановивши власну машину, яка приймає запити як "йти" та перенаправляє їх.
Сервер приймає HTTP-запити для сайту під назвою "йти" і перенаправляє запит на go.example.com. Потім ви створюєте правильні записи DNS так, щоб вони працювали, і подвійні конфігурації DHCP, щоб ваші ноутбуки / робочі станції робили правильно.
Суть цього документа про помилку сервера полягає в тому, щоб пояснити процес, а потім навести приклади конфігурації, які допоможуть зробити це для вашого сайту. Оскільки я не маю доступу до будь-якої операційної системи у світі та не знаю про це, я роблю це "вікі спільноти", щоб люди могли заповнити фрагменти конфігурації, коли вони працюватимуть для них. Я поставив "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. (Люди 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. Якщо ви хочете, щоб зовнішні машини, які не отримали VPNed, мали змогу отримати доступ до перенаправлення, може бути дивним жорсткий код corp.example.comу їх пошуковий шлях, якщо це піддомен для машин, до яких ніколи не звертаються ззовні. У цьому випадку до зовнішнього субдомену (наприклад, може бути доданий інший CNAME)ext.example.com) вказати на переспрямовувач. Оновіть конфігурацію веб-сервера для підтримки обох.
Для цього прикладу, припустимо, ви вибрали, що буде переспрямовувач go.ext.example.com. На машині можна назвати все, що завгодно, ми зробимо всю магію в DNS та конфігурації веб-сервера.
Крок 3. Планування переспрямування
Веб-сервер, який ви збираєтеся налаштувати, може бути на існуючому веб-сервері або на новому, побудованому саме для цієї мети. Ключовим моментом є те, що машина повинна бути доступною з будь-якого місця, де ви хочете працювати службою ShortName: всередині компанії, за межами компанії, коли користувач підключений через VPN. (Ви можете відмовитися від того, щоб це працювало поза компанією з міркувань безпеки. Ви можете також з міркувань безпеки встановити одну машину зсередини, а іншу - зовні.)
Примітка. Для цього не потрібно налаштовувати новий веб-сервер. Ви можете додати це на вже існуючий веб-сервер до тих пір, поки конфігурація не існує.
Примітка. Це може бути досить складним. Можливо, ви хочете зосередитись на тому, щоб ця робота працювала в найпростішому випадку, а потім, працюючи і випробувавшись, примушуйте її працювати в інших ситуаціях. Зокрема, наведіть його на роботу в такому порядку: 1. робочі станції / ноутбуки всередині компанії 2. ТОГІ машини, підключені VPN, потім машини за межами компанії (наприклад, в Інтернет-кафе). 3. ТОГО машин за межами мережі, без підключення VPN 4. ЦЕ перевірити це для інших операційних систем
У цьому прикладі ми припустимо, що є веб-сервер, який доступний за тією самою IP-адресою, незалежно від того, ви знаходитесь всередині або поза компанією.
У нашому прикладі "go. Corp .example.com" це означає, що "go" знаходиться у піддомені, доступному лише інсайдерам, і для використання послуги ShortName потрібен VPN. Оскільки Google Apps зазвичай налаштовано на роботу без VPN (оскільки весь доступ є HTTPS), це є оптимальним.
У нашому прикладі "go. Ext .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. Ext .example.com) - це Aзапис, що вказує на IP-адресу нового веб-сервера, який ви налаштовуєте.
Третій запис DNS (перенаправлення go) повинен допомогти вам при налагодженні.
Крок 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:
- Інструкції Windows DHCP
ЗРОБИТИ
- Інструкції 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 інструкції
ЗРОБИТИ
Налаштування статично налаштованих машин:
- Windows
ЗРОБИТИ
- Linux / Unix
Відредагуйте /etc/resolv.confта переконайтесь, що (1) "домен corp.example.com" є першим рядком, (2) додайте / відредагуйте рядок "пошук" для включення corp.example.comдомену, (3) додайте рядок "параметри 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 переходить до FQDN:
<a href="http://go.example.com/lunch">go/lunch</a>
Навчити людей у PR-відділі робити це може бути складно. Ви можете просто сказати їм, що вони повинні використовувати довгу версію ( go.example.com) у всьому, що вони пишуть, тому що короткий "піти / обід" працює лише випадково.
Крок 8: HTTPS
TODO: Визначте, як з HTTPS (сертифікація буде дуже складною, якщо не неможливою - правильно).