Der Blogbeitrag "Ein „Tinyurl“-Dienst für Ihre Domain" erklärt, wie Sie mit Google Apps einen ShortName-Dienst für Ihre Domäne einrichten. Wenn Ihre Domäne beispielsweise lautet example.com
und Sie Google Apps verwenden, können Sie sie so konfigurieren, dass dies der http://go.example.com
persönliche ShortName-Dienst Ihres Unternehmens ist.
HINWEIS: Es geht hier nicht darum, einen „Tinyurl“-Dienst zu erstellen, den die ganze Welt nutzen kann. Dies ist für ein Unternehmen gedacht.
Es ist nützlich, einen Kurznamendienst zu haben, den nur Ihre Benutzer verwenden können, damit Sie Links zu internen Seiten erstellen können. Anstatt den Leuten eine lange, komplizierte URL mitzuteilen, können Sie sagen: „Das Mittagsmenü für heute gibt es beihttp://go.example.com/lunch". Der Blogbeitrag dokumentiert einige der Vorteile, die sich daraus ergeben, dass man Leuten die Möglichkeit gibt, ihre eigenen Links einzurichten. (Das Wichtigste: Sie müssen SIE nicht damit belästigen, einen neuen Link einzurichten!)
Das Problem
Das Problem mit dem System ist, dass die URL immer noch ziemlich lang ist. Die Leute würden lieber "go/lunch" in ihren Webbrowser eingeben und es funktioniert. Leider kann Google Apps dies aufgrund einer technischen Besonderheit des HTTP-Protokolls nicht unterstützen. Der Header "Host:" in HTTP 1.1 listet die Domäne auf, die der Benutzer in seinen Webbrowser eingegeben hat, nicht dieVollqualifizierter Domänenname. Mit anderen Worten, wenn Google Apps die HTTP-Anforderung für "http://go/lunch" Der Webserver erhält "go" als Hostnamen. Da Google Apps diesen Dienst für viele Domänen bereitstellt, kann es nicht erkennen, ob Sie möchten go.example.com
oder nicht go.some-other-example.com
.
Dies hat zur Folge, dass Benutzer jedes Mal „go.example.com/lunch“ eingeben müssen, was viel länger dauert als „go/lunch“.
Die Lösung
Google könnte dies mithilfe von Web-Cookies oder anderen Methoden lösen. Keine davon ist besonders sauber oder einfach. Bis dahin können Sie das Problem lösen, indem Sie eine eigene Maschine einrichten, die Anfragen als „go“ akzeptiert und umleitet.
Der Server akzeptiert HTTP-Anfragen für eine Site namens „go“ und leitet die Anfrage an weiter go.example.com
. Anschließend erstellen Sie die richtigen DNS-Einträge, damit es funktioniert, und passen Ihre DHCP-Konfigurationen an, damit Ihre Laptops/Workstations das Richtige tun.
Der Zweck dieses Server Fault-Dokuments besteht darin, den Prozess zu erklären und dann Konfigurationsbeispiele bereitzustellen, die Ihnen dabei helfen, dies für Ihre Site zu tun. Da ich weder Zugriff auf alle Betriebssysteme der Welt habe noch sie kenne, mache ich daraus ein „Community-Wiki“, damit die Leute Konfigurationsausschnitte ausfüllen können, wenn sie es für sich zum Laufen bringen. Ich habe „TODO“ in die Bereiche gesetzt, die besonders verbessert werden müssen.
Die Details
In diesem Beispiel verwenden wir „example.com“ als Domäne.
Schritt 1: Richten Sie den Google Apps-Dienst wie gewohnt ein.
Konfigurieren Sie den Dienst go.example.com
wie gewohnt. Testen Sie ihn und stellen Sie sicher, dass eine URL wie diese http://go.example.com/foo
funktioniert. Fahren Sie nicht fort, wenn dies nicht abgeschlossen ist. Das wäre, als würden Sie versuchen, Ihr Auto zu reparieren, bevor Sie eines besitzen.
Schritt 2: Wählen Sie Ihren Redirector-Hostnamen
Wenn Ihr Kurznamendienst ist go.example.com
, sollten Sie den Namen Ihres Umleiters idealerweise auf setzen go.example.com
. Leider ist es aus physikalischen Gründen nicht möglich, dass sich zwei Körper gleichzeitig am gleichen Ort befinden, und DNS gehorcht den Gesetzen der Physik.
Der Trick besteht darin, dass der Umleiter denselben Hostnamen wie der ShortName-Dienst hat, sich aber in einer anderen Domäne befindet. Zum Beispiel , go.corp.example.com
, go.ext.google.com
oder go.this-is-different.example.com
.
Große Unternehmen haben normalerweise eine interne Subdomäne, die nicht der Außenwelt zugänglich ist. Normalerweise sind interne Hosts INSIDEHOST.corp.google.com
. Dort platzieren Sie den Redirector.
Einige Unternehmen weisen eine Subdomäne zu, die voller CNAMEs ist, die auf Dienste verweisen, auf die sowohl innerhalb als auch außerhalb des Unternehmens zugegriffen werden soll. Auf diese Weise gibt es eine Subdomäne, die in den DNS-Suchpfad der Benutzer eingefügt werden muss. (Unix-Benutzer können sich dies als /usr/local/bin
ein Unterverzeichnis voller symbolischer Links vorstellen.) Traditionell ist diese Subdomäne ext.example.com
. In dieser Subdomäne befinden sich CNAMEs wie mail.ext.example.com
, calendar.ext.example.com
, vpn.ext.example.com
, usw.)
Warnung: Wenn Sie Ihrem DNS-Suchpfad ein weiteres Element hinzufügen, können Sie Ihre Computer auch langsamer machen. JEDES MAL eine zusätzliche DNS-Abfrage durchzuführen ist langsam und das Surfen im Internet wird merklich langsamer. Es ist viel besser, diesen Umleiter zu einer Subdomäne hinzuzufügen, die sich bereits im DNS-Suchpfad Ihres Computers befindet, selbst wenn dies bedeutet, dass Sie einen CNAME in mehreren Subdomänen hinzufügen müssen. Wenn Ihre internen Computer und die mit Ihrem VPN verbundenen Computer beispielsweise corp.example.com
bereits in ihrem Suchpfad haben, fügen Sie den CNAME dort hinzu. Wenn externe Computer ohne VPN auf den Umleiter zugreifen sollen, wäre es möglicherweise seltsam, diesen corp.example.com
in ihren Suchpfad fest zu codieren, wenn dies die Subdomäne für Computer ist, auf die nie von außen zugegriffen wird. In diesem Fall kann ein weiterer CNAME zu einer externen Subdomäne (wie ext.example.com
) hinzugefügt werden, um auf den Umleiter zu verweisen. Aktualisieren Sie die Webserverkonfiguration, um beides zu unterstützen.
Für dieses Beispiel gehen wir davon aus, dass Sie als Umleitung ausgewählt haben go.ext.example.com
. Die Maschine kann beliebig benannt werden, wir kümmern uns um die DNS- und Webserverkonfiguration.
Schritt 3: Planen Sie Ihren Redirector
Der Webserver, den Sie einrichten, kann ein vorhandener oder ein neuer Webserver sein, der speziell für diesen Zweck erstellt wurde. Wichtig ist, dass die Maschine von überall aus zugänglich sein muss, wo der ShortName-Dienst funktionieren soll: innerhalb des Unternehmens, außerhalb des Unternehmens, wenn der Benutzer über VPN verbunden ist. (Aus Sicherheitsgründen können Sie darauf verzichten, dass dies von außerhalb des Unternehmens funktioniert. Sie können aus Sicherheitsgründen auch eine Maschine innerhalb und eine andere außerhalb des Unternehmens einrichten.)
Hinweis: Sie müssen hierfür keinen neuen Webserver aufsetzen. Sie können dies zu einem bereits vorhandenen Webserver hinzufügen, sofern die Konfiguration noch nicht vorhanden ist.
Hinweis: Dies kann ziemlich kompliziert sein. Sie sollten sich darauf konzentrieren, dies im einfachsten Fall zum Laufen zu bringen, und es dann, wenn es funktioniert und getestet wurde, für andere Situationen zum Laufen bringen. Bringen Sie es insbesondere in dieser Reihenfolge zum Laufen: 1. Arbeitsstationen/Laptops innerhalb des Unternehmens 2. DANN per VPN verbundene Maschinen, dann Maschinen außerhalb des Unternehmens (z. B. in einem Internetcafé). 3. DANN Maschinen außerhalb des Netzwerks, ohne dass das VPN aktiv ist 4. DANN testen Sie dies für andere Betriebssysteme
In diesem Beispiel gehen wir davon aus, dass ein Webserver vorhanden ist, auf den unabhängig davon, ob Sie sich innerhalb oder außerhalb des Unternehmens befinden, unter derselben IP-Adresse zugegriffen werden kann.
In unserem "Los".Unternehmen.example.com“ bedeutet dies, dass sich „go“ in einer Subdomäne befindet, die nur für Insider zugänglich ist und ein VPN erfordert, um den ShortName-Dienst zu verwenden. Da Google Apps normalerweise so konfiguriert ist, dass es ohne VPN funktioniert (weil der gesamte Zugriff über HTTPS erfolgt), ist dies nicht optimal.
In unserem "Los".ext.example.com“ bedeutet dies, dass die Subdomäne sowohl innerhalb als auch außerhalb des Unternehmens erreichbar ist und der A
Eintrag auf eine externe IP-Adresse verweist.
Schritt 4: DNS-Einträge für Ihren Redirector hinzufügen
Hier sind die erforderlichen DNS-Einträge:
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
Der erste DNS-Eintrag (go.example.com) sollte bereits im Rahmen von Schritt 1 vorhanden sein.
Der zweite DNS-Eintrag (go.ext.example.com) ist ein A
Eintrag, der auf die IP-Adresse des neuen Webservers verweist, den Sie konfigurieren.
Der dritte DNS-Eintrag (Go-Redirector) soll Ihnen beim Debuggen helfen.
Schritt 5: Konfigurieren des Webservers
Fügen Sie die Weiterleitung zum Webserver hinzu. (Dies setzt voraus, dass der Webserver bereits installiert und ausgeführt wird.)
Hier ist der Apache-Konfigurationsausschnitt:
<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>
So testen Sie dies. http://go-redirector.example.com
Sollte an dieser Stelle funktionieren.
Fahren Sie nicht fort, bis dieser Test funktioniert. Kleine Schritte.
Schritt 6: Konfigurieren Sie den DNS-Suchpfad des Clients
Jetzt konfigurieren wir die Rechner (alles, auf dem ein Webbrowser läuft) so, dass der DNS-Suchpfad „ext.example.com“ enthält.
Senden Sie an Ihren DHCP-Server und VPN-Server einen DNS-Suchpfad mit folgendem Inhalt:
corp.example.com .
(die Subdomäne mit dem Umleitungshost, gefolgt von ".")
Alternativ können Sie einen Suchpfad wie diesen verwenden:
corp.example.com example.com .
Allerdings wird dadurch für JEDE verdammte Webseite, die wir aufrufen, eine zusätzliche DNS-Suche erforderlich. Da diese in 99 % der Fälle fehlschlägt, wird das Surfen im Internet dadurch nur langsamer.
Auf Workstations und Laptops müssen Sie sicherstellen, dass die Subdomäne in ihrem DNS-Suchpfad enthalten ist. Auf diese Weise findet die Software sie in der Domäne, wenn der Benutzer „go“ eingibt.
Wir möchten den Suchpfad der Maschine so konfigurieren, dass diese Subdomäne auf jede erdenkliche Weise eingeschlossen wird:
Ursprünglich konnte der DNS-Suchpfad nicht über DHCP festgelegt werden. Dies ist eine neu hinzugefügte Funktion, die nicht von allen DHCP-Clients unterstützt wird. Sogar DHCP-Clients, die diese Funktion unterstützen, müssen geändert werden, da ein Laptop, wenn er sich beispielsweise in einem Internetcafé befindet, mit einem DHCP-Server kommuniziert, den Sie nicht steuern. Wenn ein Laptop ein VPN verwendet, verwendet die VPN-Client-Software eigentlich kein DHCP, aber es gibt normalerweise eine Möglichkeit, dass der VPN-Server die Einstellungen überträgt, die man normalerweise von einem DHCP-Server erhält.
Daher möchten Sie den DNS-Suchpfad an allen folgenden Stellen festlegen:
- Der DHCP-Server sollte die DNS-Suchpfadoptionen senden
- Bei statisch konfigurierten Maschinen sollte der DNS-Suchpfad festgelegt sein
corp.example.com
Clients, die DHCP verwenden, sollten so konfiguriert werden, dass sie die Domäne ihrem Suchpfad voranstellen, wenn der DHCP-Server sie nicht bereits aufgenommen hat.
Nachfolgend finden Sie Anweisungen dazu auf verschiedenen DHCP-Servern und Betriebssystemen.
Konfigurieren von DHCP-Servern zum Einschließen eines DNS-Suchpfads:
- Windows DHCP-Anweisungen
MACHEN
- ISC DHCP-Anweisungen
Wenn der Suchpfad nur die Domäne ist, in der sich die Maschine befinden soll, dann gilt:
option domain-name "corp.example.com";
Wenn die Clients RFC 3397 unterstützen, um einen Suchpfad bereitzustellen, können Sie dies tun, aber es ist umständlich, da es keine native Unterstützung für einen Datentyp gibt, der eine Folge von DNS-Hosts ist, die jeweils als längenpräfixierte Labels wie in DNS codiert sind. Es gibt keine Möglichkeit, die Werte einer Option zu schreiben, die als Array von Datensätzen definiert ist, wobei der Datensatz ein Array eines anderen Datensatzes enthält. Sie müssen also eine Datenzeichenfolge verwenden, um die Dinge manuell zu codieren.
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)
);
Dies sollte (ungetestet) eine Suchliste mit zwei Elementen generieren.
- dnsmasq DHCP-Anweisungen
MACHEN
Konfigurieren statisch konfigurierter Maschinen:
- Windows
MACHEN
- Linux/Unix
Bearbeiten Sie die Zeile /etc/resolv.conf
und stellen Sie sicher, dass (1) die „Domain corp.example.com“ die erste Zeile ist, (2) fügen Sie die Zeile „search“ hinzu bzw. bearbeiten Sie sie, um die corp.example.com
Domain einzuschließen, und (3) fügen Sie eine Zeile „options ndotes:2“ hinzu, um die Belastung Ihrer DNS-Server zu verringern.
domain corp.example.com
search corp.example.com exmaple.com
options ndots:2
Konfigurieren von DHCP-Clients für den Betrieb auf anderen DHCP-Servern
TODO ausfüllen für Windows, Linux usw.
Schritt 7: Testen, testen, testen!
Jetzt sollten Benutzer Folgendes angeben können:
http://go/foo http://go.example/foo http://go.example.com/foo
Um die Zuverlässigkeit zu testen, sollten Sie diese URLs in allen Situationen testen:
( each OS you support ) * ( internal LAN / at an Internet cafe / while on the VPN )
Schritt 8: Weitere Ratschläge
Und zum Schluss noch ein kleiner Ratschlag: Selbst wenn Sie alles perfekt gemacht haben, besteht immer noch das Risiko, dass ein http://go/foo
Link nicht funktioniert, wenn jemand versucht, ihn auf einem Computer einzugeben, den Sie nicht so konfiguriert haben, dass der DNS-Suchpfad Ihre Domain enthalten muss. Sie sollten daher Links unter Verwendung der vollständigen URL veröffentlichen: http://go.example.com/foo
; und sich die Zeit nehmen, die PR-Abteilung Ihres Unternehmens und andere zu schulen, dies immer so anzugeben.
Oder kodieren Sie diese zumindest in HTML, sodass im Linktext zwar „go“ sichtbar ist, der eigentliche HREF aber zum FQDN geht:
<a href="http://go.example.com/lunch">go/lunch</a>
Den Leuten in der PR-Abteilung das beizubringen, kann schwierig sein. Sie sollten ihnen vielleicht einfach sagen, dass sie go.example.com
in allem, was sie schreiben, die lange Version () verwenden müssen, weil die Kurzform „go/lunch“ nur aus Versehen funktioniert.
Schritt 8: HTTPS
TODO: Herausfinden, wie das mit HTTPS funktioniert (es wird sehr schwierig, wenn nicht unmöglich sein, die Zertifizierungen richtig hinzubekommen).
Antwort1
Diese Frage sollte auf die eine oder andere Weise als "beantwortet" markiert werden. Auf diese Weisehttps://serverfault.com/unansweredDie URL bleibt korrekt. Bitte (posten und) akzeptieren Sie eine „Antwort“ auf diese Frage. Danke!
Meine „Antwort“ wäre, dass das Erstellen (oder Installieren) eines Linkverkürzungsdienstes kinderleicht ist. Anstatt sich durch all die oben genannten Hürden zu kämpfen, richten Sie einfach einen lokalen Linkverkürzer auf einem Webserver ein, der auf „go.example.com“ antwortet, und stellen Sie sicher, dass Ihre DNS-Antworten nach example.com suchen. Auf diese Weise geben Sie keine internen URLs an die Welt weiter. (Möglicherweise verstehe ich den Punkt nicht.)
Alternativen:
Fragen Sie in einem sehr kleinen Unternehmen oder einer Arbeitsgruppe jeden nach seinen bevorzugten Lesezeichen und finden Sie Platz, um diese auf der Intranet-Startseite zu platzieren.
Alternativ können Sie das Intranet für Ihr kleines Unternehmen oder Ihre Gruppe als Wiki bereitstellen, mit einer praktischen Liste gemeinsam genutzter Hotlinks, die den Benutzern helfen, dorthin zu gelangen, wo sie wahrscheinlich hin möchten.
Grüße, -danny