Le billet de blog " Un service" tinyurl "pour votre domaine " explique comment configurer un service ShortName pour votre domaine à l'aide de Google Apps. Par exemple, si votre domaine est example.comet que vous utilisez Google Apps, vous pouvez le configurer pour qu'il http://go.example.coms'agisse du service ShortName personnel de votre entreprise.
REMARQUE: il ne s'agit pas de créer un service "tinyurl" que le monde puisse utiliser. C'est pour une entreprise.
Il est utile d'avoir un service de nom abrégé que seuls vos utilisateurs peuvent utiliser afin que vous puissiez créer des liens vers des pages internes. Plutôt que de dire aux gens une URL longue et difficile, vous pouvez dire: "Le menu du déjeuner d'aujourd'hui est sur http://go.example.com/lunch ". Le billet de blog décrit certains des avantages de permettre aux gens de créer leurs propres liens. (Le plus important: ils n'ont pas à vous déranger pour créer un nouveau lien!)
Le problème
Le problème avec le système est que l'URL est encore assez longue. Les gens préfèrent taper "go / lunch" dans leur navigateur Web et le faire fonctionner. Malheureusement, Google Apps ne peut pas prendre en charge cela en raison de la technicité du fonctionnement du protocole HTTP. L'en-tête "Host:" dans HTTP 1.1 répertorie le domaine que l'utilisateur a tapé dans son navigateur Web, pas le FQDN . En d'autres termes, lorsque Google Apps reçoit la demande HTTP pour " http: // go / lunch ", le serveur Web reçoit "go" comme nom d'hôte. Étant donné que Google Apps fournit ce service pour de nombreux domaines, il ne peut pas dire si vous le souhaitez go.example.comou go.some-other-example.com.
Par conséquent, les utilisateurs doivent à chaque fois taper "go.example.com/lunch", ce qui est beaucoup plus long que "go / lunch".
La solution
Google pourrait résoudre ce problème en utilisant des cookies Web ou un autre système. Aucun d'entre eux n'est particulièrement propre ou facile. Jusqu'à ce qu'ils le fassent, vous pouvez résoudre le problème en configurant votre propre machine qui accepte les demandes comme «aller» et les redirige.
Le serveur accepte les requêtes HTTP pour un site appelé "go" et redirige la requête vers go.example.com. Vous créez ensuite les bons enregistrements DNS pour que cela fonctionne et vous déformez vos configurations DHCP pour que vos ordinateurs portables / stations de travail fassent ce qu'il faut.
Le but de ce document Server Fault est d'expliquer le processus, puis de donner des exemples de configuration pour vous aider à le faire pour votre site. Comme je n'ai pas accès à ou ne connais pas tous les systèmes d'exploitation du monde, j'en fais un "wiki communautaire" afin que les gens puissent remplir des extraits de configuration pendant qu'ils le font fonctionner pour eux. J'ai mis 'TODO' dans un domaine qui a particulièrement besoin d'être amélioré.
Les détails
Dans cet exemple, nous utiliserons "example.com" comme domaine.
Étape 1: configurez le service Google Apps normalement.
Configurez le service go.example.comcomme d'habitude. Testez-le et assurez-vous qu'une URL similaire http://go.example.com/foofonctionne. Ne continuez pas si ce n'est pas terminé. Ce serait comme essayer de réparer votre voiture avant d'en posséder une.
Étape 2: sélectionnez le nom d'hôte de votre redirecteur
Si votre service de nom abrégé est go.example.com, idéalement, vous feriez le nom de votre redirecteur go.example.com. Malheureusement, la physique empêche deux corps d'être au même endroit en même temps, et le DNS obéit aux lois de la physique.
L'astuce consiste à faire en sorte que le redirecteur soit le même nom d'hôte que le service ShortName, mais dans un domaine différent. Par exemple, go.corp.example.com, go.ext.google.comou go.this-is-different.example.com.
Les grandes entreprises ont généralement un sous-domaine interne qui n'est pas exposé au monde extérieur. Les hôtes internes le sont généralement INSIDEHOST.corp.google.com. C'est là que vous mettez le redirecteur.
Certaines entreprises allouent un sous-domaine rempli de CNAME pointant vers des services auxquels il faut accéder à l'intérieur comme à l'extérieur de l'entreprise. De cette façon, il y a un sous-domaine qui doit être placé dans le chemin de recherche DNS des gens. (Les gens Unix peuvent penser à cela comme ayant /usr/local/binun sous-répertoire plein de liens symboliques) Traditionnellement, ce sous-domaine est ext.example.com. Dans ce sous - domaine sont CNAMEs comme mail.ext.example.com, calendar.ext.example.com, vpn.ext.example.comet ainsi de suite.)
Avertissement: l'ajout d'un autre élément à votre chemin de recherche DNS est un autre moyen de ralentir le fonctionnement de vos ordinateurs. Faire une requête DNS supplémentaire CHAQUE FOIS est lent et la navigation sur le Web sera sensiblement plus lente. Il est préférable d'ajouter ce redirecteur à un sous-domaine qui se trouve déjà dans le chemin de recherche DNS de votre machine, même si cela signifie ajouter un CNAME dans plusieurs sous-domaines. Par exemple, si vos machines internes et les machines connectées à votre VPN ont déjà corp.example.comdans leur chemin de recherche, ajoutez-y le CNAME. Si vous souhaitez que des machines externes non VPNées puissent accéder au redirecteur, il peut être étrange de coder corp.example.comen dur dans leur chemin de recherche s'il s'agit du sous-domaine des machines auxquelles on n'a jamais accédé de l'extérieur. Dans ce cas, un autre CNAME peut être ajouté à un sous-domaine externe (commeext.example.com) pour pointer vers le redirecteur. Mettez à jour la configuration du serveur Web pour prendre en charge les deux.
Pour cet exemple, supposons que vous avez sélectionné que le redirecteur le sera go.ext.example.com. La machine peut être appelée comme vous voulez, nous ferons toute la magie du DNS et de la configuration du serveur Web.
Étape 3: Planification de votre redirecteur
Le serveur Web que vous allez configurer peut se trouver sur un serveur Web existant ou sur un nouveau construit spécialement à cet effet. La clé est que la machine doit être accessible de n'importe où vous voulez que le service ShortName fonctionne: à l'intérieur de l'entreprise, à l'extérieur de l'entreprise, lorsque l'utilisateur est connecté via VPN. (Vous pouvez choisir de renoncer à ce que cela fonctionne de l'extérieur de l'entreprise pour des raisons de sécurité. Vous pouvez également, pour des raisons de sécurité, installer une machine à l'intérieur et une autre à l'extérieur.)
Remarque: Vous n'avez pas besoin de configurer un nouveau serveur Web pour cela. Vous pouvez l'ajouter à un serveur Web préexistant tant que la configuration n'existe pas.
Remarque: cela peut être assez compliqué. Vous voudrez peut-être vous concentrer sur le fonctionnement de ce logiciel dans le cas le plus simple, puis une fois que vous aurez travaillé et testé, le faire fonctionner pour d'autres situations. En particulier, faites-le fonctionner dans cet ordre: 1. postes de travail / ordinateurs portables à l'intérieur de l'entreprise 2. ALORS machines connectées par VPN, puis machines à l'extérieur de l'entreprise (par exemple, dans un cybercafé). 3. ALORS machines hors du réseau, sans VPN en place 4. ALORS testez ceci pour d'autres systèmes d'exploitation
Dans cet exemple, nous supposerons qu'un serveur Web est accessible à la même adresse IP, que vous soyez à l'intérieur ou à l'extérieur de l'entreprise.
Dans notre exemple "go. Corp .example.com", cela signifie que le "go" se trouve dans un sous-domaine qui n'est accessible qu'aux initiés et nécessite un VPN pour utiliser le service ShortName. Étant donné que Google Apps est généralement configuré pour fonctionner sans VPN (car tous les accès sont HTTPS), cela n'est pas optimal.
Dans notre exemple "go. Ext .example.com", cela signifie que le sous-domaine est accessible à l'intérieur et à l'extérieur de l'entreprise et que l' Aenregistrement pointe vers une adresse IP externe.
Étape 4: ajouter des enregistrements DNS pour votre redirecteur
Voici les enregistrements DNS requis:
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
Le premier enregistrement DNS (go.example.com) doit déjà exister dans le cadre de l'étape 1.
Le deuxième enregistrement DNS (go. Ext .example.com) est un Aenregistrement pointant vers l'adresse IP du nouveau serveur Web que vous configurez.
Le troisième enregistrement DNS (go-redirector) est pour vous aider lors du débogage.
Étape 5: configurer le serveur Web
Ajoutez la redirection vers le serveur Web. (Cela suppose que le serveur Web est déjà installé et fonctionne).
Voici l'extrait de configuration 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>
Comment tester cela. http://go-redirector.example.comdevrait fonctionner à ce stade.
Ne continuez pas tant que ce test ne fonctionne pas. Pas de bébé.
Étape 6: configurer le chemin de recherche DNS du client
Nous allons maintenant configurer les machines (tout ce qui exécute un navigateur Web) afin que le chemin de recherche DNS inclue "ext.example.com"
Sur votre serveur DHCP et votre serveur VPN, envoyez un chemin de recherche DNS qui est:
corp.example.com.
(le sous-domaine avec l'hôte de redirection, suivi de ".")
Vous pouvez également utiliser un chemin de recherche comme:
corp.example.com example.com.
Cependant, cela va ajouter une recherche DNS supplémentaire pour CHAQUE page Web que nous visitons. Comme ils échoueront 99% du temps, cela va simplement ralentir la navigation sur le Web.
Sur les postes de travail et les ordinateurs portables, vous devez vous assurer que le sous-domaine est inclus dans leur chemin de recherche DNS. De cette façon, lorsque l'utilisateur tape "go", le logiciel le trouve dans le domaine.
Nous voulons configurer le chemin de recherche de la machine pour inclure ce sous-domaine dans tous les sens où le chemin de recherche peut éventuellement être défini:
À l'origine, le chemin de recherche DNS ne pouvait pas être défini via DHCP. Il s'agit d'une fonctionnalité nouvellement ajoutée et tous les clients DHCP ne la prennent pas en charge. Même les clients DHCP qui le prennent en charge doivent être modifiés car lorsqu'un ordinateur portable se trouve (par exemple) dans un cybercafé, il parle à un serveur DHCP que vous ne contrôlez pas. Lorsqu'un ordinateur portable utilise un VPN, le logiciel client VPN n'utilise pas réellement DHCP, mais il existe généralement un moyen pour le serveur VPN de transmettre les paramètres que l'on obtient généralement d'un serveur DHCP.
Par conséquent, vous souhaitez définir le chemin de recherche DNS à tous ces endroits:
- Le serveur DHCP doit envoyer les options du chemin de recherche DNS
- Les machines configurées statiquement doivent avoir leur chemin de recherche DNS défini
- Les clients qui utilisent DHCP doivent être configurés pour ajouter le
corp.example.comdomaine à leur chemin de recherche si le serveur DHCP ne l'a pas déjà inclus.
Vous trouverez ci-dessous des instructions sur la façon de procéder sur divers serveurs DHCP et systèmes d'exploitation.
Configuration des serveurs DHCP pour inclure un chemin de recherche DNS:
- Instructions DHCP Windows
FAIRE
- Instructions DHCP ISC
Si le chemin de recherche est juste le domaine dans lequel la machine doit se trouver, alors:
option domain-name "corp.example.com";
Si les clients prennent en charge la RFC 3397 pour fournir un chemin de recherche, vous pouvez le faire, mais c'est gênant car il n'y a pas de prise en charge native pour un type de données qui est une séquence d'hôtes DNS, chacun codé en tant qu'étiquettes à préfixe de longueur comme dans DNS. Il n'y a aucun moyen d'écrire les valeurs d'une option définie comme un tableau d'enregistrements, où l'enregistrement contient un tableau d'un autre enregistrement, vous devez donc utiliser une chaîne de données pour coder les choses manuellement.
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)
);
qui devrait (non testé) générer une liste de recherche de deux éléments.
- instructions DHCP dnsmasq
FAIRE
Configuration de machines configurées statiquement:
- les fenêtres
FAIRE
- Linux / Unix
Modifiez /etc/resolv.confet assurez-vous (1) que le "domaine corp.example.com" est la première ligne, (2) ajoutez / modifiez la ligne "recherche" pour inclure le corp.example.comdomaine, (3) ajoutez une ligne "options ndotes: 2" à réduire la charge sur vos serveurs DNS.
domain corp.example.com
search corp.example.com exmaple.com
options ndots:2
Configuration des clients DHCP pour qu'ils fonctionnent sur d'autres serveurs DHCP
TODO à remplir pour Windows, Linux, etc.
Étape 7: Testez, testez, testez!
Les utilisateurs devraient maintenant pouvoir spécifier:
http: // go / foo http: //go.example/foo http://go.example.com/foo
En fait, comme test de confiance, vous voudrez tester ces URL dans toutes les situations:
( each OS you support ) * ( internal LAN / at an Internet cafe / while on the VPN )
Étape 8: Autres conseils
Et enfin, un petit conseil: même si vous aviez fait un travail parfait, vous courez toujours le risque qu'un http://go/foolien ne fonctionne pas lorsqu'une personne essaie de le taper sur un ordinateur que vous n'avez pas configuré pour forcer la recherche DNS chemin pour inclure votre domaine. Vous devriez donc publier des liens en utilisant l'URL complète: http://go.example.com/foo; et prenez le temps d'éduquer le service des relations publiques de votre entreprise et d'autres pour toujours le spécifier de cette façon.
Ou au moins les encoder en HTML pour que "go" soit visible dans le texte du lien, mais le HREF réel va au FQDN:
<a href="http://go.example.com/lunch">go/lunch</a>
Il peut être difficile d'apprendre aux gens du service des relations publiques à le faire. Vous voudrez peut-être simplement leur dire qu'ils doivent utiliser la version longue ( go.example.com) dans tout ce qu'ils écrivent parce que le court "go / lunch" ne fonctionne que par accident.
Étape 8: HTTPS
TODO: Découvrez comment faire avec HTTPS (les certifications vont être très difficiles, voire impossibles, à obtenir correctement).