La publicación del blog " Un servicio 'tinyurl' para su dominio " explica cómo configurar un servicio ShortName para su dominio utilizando Google Apps. Por ejemplo, si su dominio es example.comy usa Google Apps, puede configurarlo para que http://go.example.comsea el servicio ShortName personal de su empresa.
NOTA: No se trata de crear un servicio "tinyurl" para que el mundo lo use. Esto es para una empresa.
Es útil tener un servicio de nombre corto que solo sus usuarios puedan usar para que pueda crear enlaces a páginas internas. En lugar de decirle a la gente una URL larga y difícil, puede decir: "El menú del almuerzo de hoy está en http://go.example.com/lunch ". La publicación del blog documenta algunos de los beneficios de capacitar a las personas para que creen sus propios enlaces. (Lo más importante: ¡no tienen que molestarte para configurar un nuevo enlace!)
El problema
El problema con el sistema es que la URL todavía es bastante larga. La gente prefiere escribir "go / lunch" en su navegador web y hacer que funcione. Lamentablemente, Google Apps no puede soportar esto debido a un tecnicismo de cómo funciona el protocolo HTTP. El encabezado "Host:" en HTTP 1.1 enumera el dominio que el usuario escribió en su navegador web, no el FQDN . En otras palabras, cuando Google Apps recibe la solicitud HTTP para " http: // go / lunch ", el servidor web recibe "go" como nombre de host. Como Google Apps proporciona este servicio para muchos dominios, no puede saber si lo desea go.example.como no go.some-other-example.com.
Como resultado, los usuarios tienen que escribir "go.example.com/lunch" cada vez, que es mucho más largo que "go / lunch".
La solución
Google podría resolver esto mediante el uso de cookies web o algún otro esquema. Ninguno de los cuales es particularmente limpio o fácil. Hasta que lo hagan, puede resolver el problema configurando una máquina propia que acepte las solicitudes como "ir" y las redirija.
El servidor acepta solicitudes HTTP para un sitio llamado "ir" y redirige la solicitud a go.example.com. Luego crea los registros DNS correctos para que funcione, y cambia las configuraciones de DHCP para que sus computadoras portátiles / estaciones de trabajo hagan lo correcto.
El objetivo de este documento de Falla del servidor es explicar el proceso y luego dar ejemplos de configuración para ayudarlo a hacer esto en su sitio. Como no tengo acceso ni conocimiento de todos los sistemas operativos del mundo, estoy haciendo de esto un "wiki comunitario" para que las personas puedan completar fragmentos de configuración a medida que lo hacen funcionar para ellos. Puse 'TODO' en un área que particularmente necesita mejoras.
Los detalles
En este ejemplo usaremos "ejemplo.com" como dominio.
Paso 1: configura el servicio Google Apps de la forma habitual.
Configure el servicio para go.example.comlo normal. Pruébelo y asegúrese de que una URL como http://go.example.com/foofunciona. No continúe si esto no está completo. Eso sería como tratar de reparar su automóvil antes de tener uno.
Paso 2: Seleccione su nombre de host redirector
Si su servicio de nombre corto es go.example.com, idealmente haría el nombre de su redirector go.example.com. Lamentablemente, la física evita que dos cuerpos estén en el mismo lugar al mismo tiempo, y el DNS obedece las leyes de la física.
El truco consiste en que el redirector sea el mismo nombre de host que el servicio ShortName, pero en un dominio diferente. Por ejemplo, go.corp.example.com, go.ext.google.com, o go.this-is-different.example.com.
Las grandes empresas suelen tener un subdominio interno que no está expuesto al mundo exterior. Por lo general, los hosts internos son INSIDEHOST.corp.google.com. Ahí es donde pones el redirector.
Algunas compañías asignan un subdominio que está lleno de CNAME que apuntan a servicios a los que se debe acceder desde dentro y fuera de la compañía. De esa manera, hay un subdominio que debe colocarse en la ruta de búsqueda DNS de las personas. (La gente de Unix puede pensar que esto /usr/local/bines un subdirectorio lleno de enlaces simbólicos) Tradicionalmente este subdominio es ext.example.com. En ese subdominio son CNAMEs como mail.ext.example.com, calendar.ext.example.com, vpn.ext.example.com, y así sucesivamente).
Advertencia: agregar otro elemento a su ruta de búsqueda de DNS es otra forma de hacer que sus computadoras funcionen más lentamente. Hacer una consulta DNS adicional CADA VEZ es lenta y navegar por la web será notablemente más lento. Es mucho mejor agregar este redirector a un subdominio que ya está en la ruta de búsqueda DNS de su máquina, incluso si esto significa agregar un CNAME en múltiples subdominios. Por ejemplo, si sus máquinas internas y las máquinas conectadas a su VPN ya tienen corp.example.comsu ruta de búsqueda, agregue el CNAME allí. Si desea que máquinas externas que no estén conectadas por VPN puedan acceder al redirector, puede ser extraño codificar corp.example.comen su ruta de búsqueda si ese es el subdominio para máquinas a las que nunca se accede desde afuera. En ese caso, se puede agregar otro CNAME a un subdominio externo (comoext.example.com) para apuntar al redirector. Actualice la configuración del servidor web para admitir ambos.
Para este ejemplo, supongamos que ha seleccionado que será el redirector go.ext.example.com. La máquina se puede llamar como quieras, haremos toda la magia en DNS y la configuración del servidor web.
Paso 3: planea tu redirector
El servidor web que va a configurar puede estar en un servidor web existente o en uno nuevo creado solo para este propósito. La clave es que la máquina debe ser accesible desde cualquier lugar donde desee que funcione el servicio ShortName: dentro de la empresa, fuera de la empresa, cuando el usuario está conectado a través de VPN. (Puede optar por renunciar a que esto funcione desde fuera de la empresa por razones de seguridad. También puede, por razones de seguridad, configurar una máquina en el interior y otra en el exterior).
Nota: No tiene que configurar un nuevo servidor web para esto. Puede agregar esto a un servidor web preexistente siempre que la configuración no exista.
Nota: Esto puede ser bastante complicado. Es posible que desee centrarse en hacer que esto funcione en el caso más simple, luego, una vez que funcione y se pruebe, que funcione para otras situaciones. En particular, haga que funcione en este orden: 1. estaciones de trabajo / computadoras portátiles dentro de la compañía 2. ENTONCES máquinas conectadas por VPN, luego máquinas fuera de la compañía (por ejemplo, en un cibercafé). 3. ENTONCES máquinas fuera de la red, sin la VPN activada 4. ENTONCES pruebe esto para otros sistemas operativos
En este ejemplo, asumiremos que hay un servidor web al que se puede acceder desde la misma dirección IP, ya sea que se encuentre dentro o fuera de la empresa.
En nuestro "ir. Corp ejemplo .example.com", esto significa que el "Go" está en un subdominio que sólo se puede acceder a información privilegiada, y requiere una VPN para utilizar el servicio ShortName. Dado que Google Apps generalmente está configurado para funcionar sin una VPN (porque todo el acceso es HTTPS), esto es subóptimo.
En nuestro "ir. Ext ejemplo .example.com", esto significa que el subdominio es accesible desde dentro y fuera de la empresa, y los Apuntos de registro a una dirección IP externa.
Paso 4: Agregue registros DNS para su redirector
Aquí están los registros DNS requeridos:
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
El primer registro DNS (go.example.com) ya debería existir como parte del Paso 1.
El segundo registro DNS (ir. Ext .example.com) es un Aseñalador de registro en la dirección IP del nuevo servidor web que está configurando.
El tercer registro DNS (go-redirector) es para ayudarlo al depurar.
Paso 5: configurar el servidor web
Agregue la redirección al servidor web. (Esto supone que el servidor web ya está instalado y ejecutándose).
Aquí está el fragmento de configuración de 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>
Cómo probar esto http://go-redirector.example.comdebería funcionar en este punto.
No continúe hasta que esta prueba funcione. Pequeños pasos.
Paso 6: Configure la ruta de búsqueda DNS del cliente
Ahora vamos a configurar máquinas (cualquier cosa que ejecute un navegador web) para que la ruta de búsqueda DNS incluya "ext.example.com"
En su servidor DHCP y servidor VPN, envíe una ruta de búsqueda DNS que sea:
corp.example.com.
(el subdominio con el host de redireccionamiento, seguido de ".")
Alternativamente, podría usar una ruta de búsqueda como:
corp.example.com example.com.
Sin embargo, eso agregará una búsqueda de DNS adicional para CADA maldita página web a la que vayamos. Dado que fallarán el 99% del tiempo, eso solo hará que la navegación web sea lenta.
En estaciones de trabajo y computadoras portátiles, debe asegurarse de que el subdominio esté incluido en su ruta de búsqueda DNS. De esa manera, cuando el usuario escribe "ir", el software lo encontrará en el dominio.
Queremos configurar la ruta de búsqueda de la máquina para incluir este subdominio en todas las formas en que la ruta de búsqueda se pueda configurar:
Originalmente, la ruta de búsqueda de DNS no se podía establecer a través de DHCP. Esta es una característica recientemente agregada y no todos los clientes DHCP lo admiten. Incluso los clientes DHCP que lo admiten deben modificarse porque cuando una computadora portátil está (por ejemplo) en un cibercafé, está hablando con un servidor DHCP que usted no controla. Cuando una computadora portátil usa una VPN, el software del cliente VPN en realidad no usa DHCP, pero generalmente hay alguna forma en que el servidor VPN transmite la configuración que normalmente se obtendría de un servidor DHCP.
Por lo tanto, desea establecer la ruta de búsqueda DNS en todos estos lugares:
- El servidor DHCP debe enviar las opciones de ruta de búsqueda DNS
- Las máquinas configuradas estáticamente deben tener su ruta de búsqueda DNS establecida
- Los clientes que usan DHCP deben configurarse para pre-pendular el
corp.example.comdominio a su ruta de búsqueda si el servidor DHCP no lo incluye ya.
A continuación hay instrucciones sobre cómo hacer esto en varios servidores DHCP y sistemas operativos.
Configuración de servidores DHCP para incluir una ruta de búsqueda DNS:
- Instrucciones de DHCP de Windows
QUE HACER
- ISC DHCP instrucciones
Si la ruta de búsqueda es solo el dominio en el que debe estar la máquina, entonces:
option domain-name "corp.example.com";
Si los clientes admiten RFC 3397 para proporcionar una ruta de búsqueda, puede hacer esto, pero es incómodo ya que no hay soporte nativo para un tipo de datos que es una secuencia de hosts DNS, cada uno codificado como etiquetas con longitud prefijada como en DNS. No hay forma de escribir los valores de una opción definida como una matriz de registros, donde el registro contiene una matriz de otro registro, por lo que tiene que usar una cadena de datos para codificar cosas manualmente.
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)
);
que debería (sin probar) generar una lista de búsqueda de dos elementos.
- Instrucciones DHCP de dnsmasq
QUE HACER
Configuración de máquinas configuradas estáticamente:
- Ventanas
QUE HACER
- Linux / Unix
Edite /etc/resolv.confy asegúrese de que (1) el "dominio corp.example.com" sea la primera línea, (2) agregue / edite la línea de "búsqueda" para incluir el corp.example.comdominio, (3) agregue una línea de "opciones ndotes: 2" a reduzca la carga en sus servidores DNS.
domain corp.example.com
search corp.example.com exmaple.com
options ndots:2
Configurar clientes DHCP para que funcionen en otros servidores DHCP
TODO complete para Windows, Linux, etc.
Paso 7: ¡Prueba, prueba, prueba!
Ahora los usuarios deberían poder especificar:
http: // go / foo http: //go.example/foo http://go.example.com/foo
De hecho, como prueba de confianza, querrás probar esas URL en todas las situaciones:
( each OS you support ) * ( internal LAN / at an Internet cafe / while on the VPN )
Paso 8: otro consejo
Y, por último, un pequeño consejo: incluso si hubiera hecho un trabajo perfecto de esto, aún corre el riesgo de que un http://go/fooenlace no funcione cuando una persona intenta escribirlo en una computadora que no configuró para forzar la búsqueda de DNS ruta para incluir su dominio. Usted debe, por lo tanto, publicar enlaces utilizando el URL completo: http://go.example.com/foo; y tómese el tiempo para educar al departamento de relaciones públicas de su empresa y a otros para especificarlo siempre de esa manera.
O al menos codifíquelos en HTML para que "ir" sea visible en el texto del enlace, pero el HREF real va al FQDN:
<a href="http://go.example.com/lunch">go/lunch</a>
Enseñar a las personas en el departamento de relaciones públicas a hacer esto puede ser difícil. Es posible que desee decirles que tienen que usar la versión larga ( go.example.com) en cualquier cosa que escriban porque el breve "ir / almorzar" solo funciona por accidente.
Paso 8: HTTPS
TODO: descubra cómo hacer con HTTPS (las certificaciones serán muy difíciles, si no imposibles, de acertar).