A postagem do blog " Um serviço 'tinyurl' para seu domínio " explica como configurar um serviço ShortName para seu domínio usando o Google Apps. Por exemplo, se seu domínio é example.come você usa o Google Apps, é possível configurá-lo para que http://go.example.comseja o serviço ShortName pessoal da sua empresa.
NOTA: Não se trata de criar um serviço "tinyurl" para o mundo usar. Isto é para uma empresa.
É útil ter um serviço de nome abreviado que somente seus usuários possam usar para que você possa criar links para páginas internas. Em vez de informar às pessoas um URL longo e difícil, você pode dizer: "O menu do almoço de hoje está em http://go.example.com/lunch ". A postagem do blog documenta alguns dos benefícios de capacitar as pessoas a criar seus próprios links. (O mais importante: eles não precisam se preocupar em criar um novo link!)
O problema
O problema com o sistema é que o URL ainda é bastante longo. As pessoas preferem digitar "ir / almoçar" no navegador da web e fazê-lo funcionar. Infelizmente, o Google Apps não suporta isso devido a um detalhe técnico de como o protocolo HTTP funciona. O cabeçalho "Host:" no HTTP 1.1 lista o domínio que o usuário digitou no navegador da Web, não o FQDN . Em outras palavras, quando o Google Apps recebe a solicitação HTTP para " http: // go / lunch ", o servidor recebe "go" como o nome do host. Como o Google Apps está fornecendo esse serviço para muitos domínios, não é possível saber se você deseja go.example.comou go.some-other-example.com.
Como resultado, os usuários precisam digitar "go.example.com/lunch" toda vez, o que é muito mais longo do que "go / lunch".
A solução
O Google poderia resolver isso usando cookies da web ou algum outro esquema. Nenhum dos quais é particularmente limpo ou fácil. Até que você resolva o problema, configure uma máquina que aceite solicitações como "vá" e as redirecione.
O servidor aceita solicitações HTTP para um site chamado "go" e redireciona a solicitação para go.example.com. Em seguida, você cria os registros DNS corretos para que funcionem e modifica suas configurações de DHCP para que seus laptops / estações de trabalho façam a coisa certa.
O objetivo deste documento de Falha no servidor é explicar o processo e fornecer exemplos de configuração para ajudá-lo a fazer isso no seu site. Como não tenho acesso ou conhecimento de todos os sistemas operacionais do mundo, estou transformando este um "wiki da comunidade" para que as pessoas possam preencher trechos de configuração à medida que o fazem funcionar para eles. Eu coloquei 'TODO' em uma área que particularmente precisa de melhorias.
Os detalhes
Neste exemplo, usaremos "example.com" como o domínio.
Etapa 1: configure o serviço do Google Apps da maneira normal.
Configure o serviço go.example.comnormalmente. Teste e verifique se um URL http://go.example.com/foofunciona. Não continue se isso não estiver completo. Seria como tentar consertar seu carro antes de você possuir um.
Etapa 2: selecione seu nome de host do redirecionador
Se o seu serviço de nome abreviado for go.example.com, o ideal seria criar o nome do seu redirecionador go.example.com. Infelizmente, a física impede que dois corpos estejam no mesmo lugar ao mesmo tempo, e o DNS obedece às leis da física.
O truque é fazer com que o redirecionador seja o mesmo nome de host que o serviço ShortName, mas em um domínio diferente. Por exemplo, go.corp.example.com, go.ext.google.com, ou go.this-is-different.example.com.
As grandes empresas geralmente têm um subdomínio interno que não é exposto ao mundo exterior. Normalmente, os hosts internos são INSIDEHOST.corp.google.com. É aí que você coloca o redirecionador.
Algumas empresas alocam um subdomínio cheio de CNAMEs, apontando para serviços que devem ser acessados de dentro e de fora da empresa. Dessa forma, há um subdomínio que precisa ser colocado no caminho de pesquisa DNS das pessoas. (As pessoas do Unix podem pensar nisso como /usr/local/binum subdiretório cheio de links simbólicos). Tradicionalmente, esse subdomínio é ext.example.com. Nesse subdomínio são CNAMEs como mail.ext.example.com, calendar.ext.example.com, vpn.ext.example.come assim por diante.)
Aviso: a adição de outro item ao caminho de pesquisa do DNS é outra maneira de tornar os computadores mais lentos. Fazer uma consulta DNS adicional TODAS AS VEZES é lento e a navegação na Web fica visivelmente mais lenta. É muito melhor adicionar esse redirecionador a um subdomínio que já esteja no caminho de pesquisa DNS da sua máquina, mesmo que isso signifique adicionar um CNAME em vários subdomínios. Por exemplo, se suas máquinas internas e as máquinas conectadas à sua VPN já tiverem corp.example.como caminho de pesquisa, adicione o CNAME lá. Se você deseja que máquinas externas não conectadas por VPN possam acessar o redirecionador, pode ser estranho codificar corp.example.comno caminho de pesquisa se esse for o subdomínio das máquinas nunca acessadas de fora. Nesse caso, outro CNAME pode ser adicionado a um subdomínio externo (comoext.example.com) para apontar para o redirecionador. Atualize a configuração do servidor da web para suportar os dois.
Neste exemplo, vamos supor que você tenha selecionado que o redirecionador será go.ext.example.com. A máquina pode ser chamada como você quiser, faremos toda a mágica no DNS e na configuração do servidor web.
Etapa 3: planejando seu redirecionador
O servidor da Web que você irá configurar pode estar em um servidor da Web existente ou em um novo criado apenas para esse fim. A chave é que a máquina deve estar acessível de qualquer lugar em que você queira que o serviço ShortName funcione: dentro da empresa, fora da empresa, quando o usuário estiver conectado via VPN. (Você pode optar por não fazê-lo funcionar fora da empresa por motivos de segurança. Você também pode, por motivos de segurança, configurar uma máquina por dentro e outra por fora.)
Nota: Você não precisa configurar um novo servidor web para isso. Você pode adicionar isso a um servidor Web preexistente, desde que a configuração não exista.
Nota: Isso pode ser bastante complicado. Você pode se concentrar em fazer isso funcionar no caso mais simples; depois de trabalhar e testar, faça-o funcionar para outras situações. Em particular, faça-o funcionar nesta ordem: 1. estações de trabalho / laptops dentro da empresa 2. ENTÃO máquinas conectadas por VPN, depois máquinas fora da empresa (por exemplo, em uma sala de Internet). 3. ENTÃO máquinas fora da rede, sem a VPN ativada 4. ENTÃO teste isso para outros sistemas operacionais
Neste exemplo, assumiremos que existe um servidor da Web acessível no mesmo endereço IP, esteja você dentro ou fora da empresa.
No nosso exemplo "go. Corp .example.com", isso significa que o "go" está em um subdomínio que é acessível apenas a usuários internos e requer uma VPN para usar o serviço ShortName. Como o Google Apps geralmente é configurado para funcionar sem uma VPN (porque todo o acesso é HTTPS), isso não é ideal.
No exemplo "go. Ext .example.com", isso significa que o subdomínio pode ser acessado dentro e fora da empresa, e o Aregistro aponta para um endereço IP externo.
Etapa 4: adicionar registros DNS ao seu redirecionador
Aqui estão os registros DNS necessários:
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
O primeiro registro DNS (go.example.com) já deve existir como parte da Etapa 1.
O segundo registro DNS (vá. Ext .example.com) é um Aregistro apontando para o endereço IP do novo servidor da web que você está configurando.
O terceiro registro DNS (redirecionador go) é para ajudá-lo na depuração.
Etapa 5: configurar o servidor da web
Adicione o redirecionamento ao servidor web. (Isso pressupõe que o servidor web já esteja instalado e em execução).
Aqui está o trecho de configuração do 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>
Como testar isso. http://go-redirector.example.comdeve funcionar neste momento.
Não continue até que este teste funcione. Passos de bebê.
Etapa 6: configurar o caminho de pesquisa DNS do cliente
Agora vamos configurar máquinas (qualquer coisa que esteja executando um navegador da Web) para que o caminho de pesquisa do DNS inclua "ext.example.com"
No servidor DHCP e no servidor VPN, envie um caminho de pesquisa DNS que seja:
corp.example.com.
(o subdomínio com o host de redirecionamento, seguido por ".")
Como alternativa, você pode usar um caminho de pesquisa como:
corp.example.com example.com.
No entanto, isso adicionará uma pesquisa de DNS adicional para TODAS as páginas da web que acessamos. Como eles falham 99% do tempo, isso tornará a navegação na web lenta.
Em estações de trabalho e laptops, é necessário garantir que o subdomínio esteja incluído no caminho de pesquisa do DNS. Dessa forma, quando o usuário digita "go", o software o encontra no domínio.
Queremos configurar o caminho de pesquisa da máquina para incluir esse subdomínio de todas as formas possíveis para o caminho de pesquisa:
Originalmente, o caminho de pesquisa do DNS não podia ser definido via DHCP. Esse é um recurso recém-adicionado e nem todos os clientes DHCP o suportam. Mesmo os clientes DHCP que o suportam precisam ser modificados porque, quando um laptop está em (por exemplo) uma sala de Internet, ele está conversando com um servidor DHCP que você não controla. Quando um laptop usa uma VPN, o software cliente VPN na verdade não usa DHCP, mas geralmente existe uma maneira de o servidor VPN transmitir as configurações que normalmente seriam obtidas de um servidor DHCP.
Portanto, você deseja definir o caminho de pesquisa do DNS em todos esses lugares:
- O servidor DHCP deve enviar as opções do caminho de pesquisa DNS
- Máquinas configuradas estaticamente devem ter seu caminho de pesquisa DNS definido
- Os clientes que usam DHCP devem ser configurados para pré-pendurar o
corp.example.comdomínio no caminho de pesquisa, se o servidor DHCP ainda não o incluiu.
Abaixo estão as instruções sobre como fazer isso em vários servidores DHCP e sistemas operacionais.
Configurando servidores DHCP para incluir um caminho de pesquisa DNS:
- Instruções DHCP do Windows
FAÇAM
- Instruções DHCP do ISC
Se o caminho de pesquisa for apenas o domínio em que a máquina deve estar, então:
option domain-name "corp.example.com";
Se os clientes suportam o RFC 3397 para fornecer um caminho de pesquisa, você pode fazer isso, mas é estranho, pois não há suporte nativo para um tipo de dados que é uma sequência de hosts DNS, cada um codificado como rótulos com prefixo de comprimento, como no DNS. Não há como escrever os valores de uma opção definida como uma matriz de registros, onde o registro contém uma matriz de outro registro; portanto, você deve usar uma sequência de dados para codificar as coisas 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 deve (não testado) gerar uma lista de pesquisa de dois itens.
- Instruções DHCP do dnsmasq
FAÇAM
Configurando máquinas configuradas estaticamente:
- janelas
FAÇAM
- Linux / Unix
Edite /etc/resolv.confe verifique se (1) o "domínio corp.example.com" é a primeira linha, (2) adicione / edite a linha "pesquisar" para incluir o corp.example.comdomínio, (3) adicione uma linha "options ndotes: 2" para reduza a carga nos seus servidores DNS.
domain corp.example.com
search corp.example.com exmaple.com
options ndots:2
Configurando clientes DHCP para funcionar quando em outros servidores DHCP
TODO preenche para Windows, Linux, etc.
Etapa 7: Teste, teste, teste!
Agora os usuários devem poder especificar:
http: // go / foo http: //go.example/foo http://go.example.com/foo
De fato, como um teste de confiança, convém testar esses URLs em todas as situações:
( each OS you support ) * ( internal LAN / at an Internet cafe / while on the VPN )
Etapa 8: Outros conselhos
E, finalmente, um pequeno conselho: mesmo que você tenha feito um trabalho perfeito, você ainda corre o risco de um http://go/foolink não funcionar quando uma pessoa tenta digitá-lo em um computador que você não configurou para forçar a pesquisa de DNS. caminho para incluir seu domínio. Você deve, portanto, publicar links usando a URL completa: http://go.example.com/foo; e reserve um tempo para educar o departamento de relações públicas da sua empresa e outras pessoas para sempre especificá-lo dessa maneira.
Ou pelo menos codifique-os em HTML para que "go" fique visível no texto do link, mas o HREF real vai para o FQDN:
<a href="http://go.example.com/lunch">go/lunch</a>
Ensinar as pessoas do departamento de relações públicas a fazer isso pode ser difícil. Você pode apenas dizer que eles precisam usar a versão longa ( go.example.com) em qualquer coisa que escrevem, porque o pequeno "ir / almoço" funciona apenas por acidente.
Etapa 8: HTTPS
TODO: Descubra como lidar com o HTTPS (as certificações serão muito difíceis, se não impossíveis, de acertar).