A postagem do blog "Um serviço 'tinyurl' para o seu domínio" explica como configurar um serviço ShortName para seu domínio usando o Google Apps. Por exemplo, se seu domínio for example.com
e você usar o Google Apps, você poderá configurá-lo para que http://go.example.com
seja o serviço ShortName pessoal de 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 shortname 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 cardápio do almoço de hoje é àshttp://go.example.com/lunch". A postagem do blog documenta alguns dos benefícios de capacitar as pessoas para configurar seus próprios links. (O mais importante: eles não precisam incomodar VOCÊ para configurar um novo link!)
O problema
O problema do sistema é que a URL ainda é bastante longa. As pessoas preferem digitar “go/lunch” em seus navegadores e fazer com que funcione. Infelizmente, o Google Apps não oferece suporte a 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 em seu navegador, não o domínioFQDN. Em outras palavras, quando o Google Apps recebe a solicitação HTTP para "http://go/almoço" o servidor da web recebe "go" como nome do host. Como o Google Apps fornece esse serviço para muitos domínios, ele não pode dizer se você deseja go.example.com
ou go.some-other-example.com
.
Como resultado, os usuários precisam digitar "go.example.com/lunch" todas as vezes, 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 isso aconteça, você pode resolver o problema configurando sua própria máquina que aceita solicitações como "go" e as redireciona.
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 altera suas configurações de DHCP para que seus laptops/estações de trabalho façam a coisa certa.
O objetivo deste documento de falha do servidor é explicar o processo e, em seguida, fornecer exemplos de configuração para ajudá-lo a fazer isso em seu site. Como não tenho acesso ou conhecimento de todos os sistemas operacionais do mundo, estou tornando este um "wiki da comunidade" para que as pessoas possam preencher trechos de configuração à medida que o fazem funcionar para elas. Coloquei 'TODO' nas áreas que precisam ser melhoradas.
Os detalhes
Neste exemplo usaremos "example.com" como domínio.
Etapa 1: configure o serviço Google Apps normalmente.
Configure o serviço go.example.com
normalmente. Teste-o e certifique-se de que um URL como este http://go.example.com/foo
funcione. Não continue se isso não estiver completo. Isso seria como tentar consertar seu carro antes de adquirir um.
Etapa 2: selecione o nome de host do redirecionador
Se o seu serviço de nome abreviado for go.example.com
, o ideal é que você crie 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 tenha o mesmo nome de host do 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 possuem um subdomínio interno que não fica exposto ao mundo exterior. Geralmente 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 tanto dentro quanto fora da empresa. Dessa forma, há um subdomínio que precisa ser colocado no caminho de busca do DNS das pessoas. (As pessoas do Unix podem pensar nisso como /usr/local/bin
um subdiretório cheio de links simbólicos) Tradicionalmente, esse subdomínio é ext.example.com
. Nesse subdomínio estão CNAMEs como mail.ext.example.com
, calendar.ext.example.com
, vpn.ext.example.com
e assim por diante.)
Aviso: Adicionar outro item ao caminho de pesquisa do DNS é outra maneira de tornar seus computadores mais lentos. Fazer uma consulta DNS adicional TODAS AS VEZES é lento e navegar na web será visivelmente mais lento. É muito melhor adicionar este 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 máquinas conectadas à sua VPN corp.example.com
já tiverem seu caminho de pesquisa, adicione o CNAME lá. Se você deseja que máquinas externas sem VPN possam acessar o redirecionador, pode ser estranho codificar corp.example.com
seu caminho de pesquisa se esse for o subdomínio para máquinas nunca acessadas externamente. Nesse caso, outro CNAME pode ser adicionado a um subdomínio externo (como ext.example.com
) para apontar para o redirecionador. Atualize a configuração do servidor web para suportar ambos.
Para este exemplo, vamos supor que você selecionou que o redirecionador será go.ext.example.com
. A máquina pode ter o nome que você quiser, nós faremos toda a mágica no DNS e na configuração do servidor web.
Etapa 3: planejando seu redirecionador
O servidor web que você vai configurar pode estar em um servidor web existente ou em um novo construído apenas para essa finalidade. O segredo é que a máquina deve ser acessível de qualquer lugar onde 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 permitir que isso funcione fora da empresa por motivos de segurança. Você também pode, por motivos de segurança, configurar uma máquina internamente e outra externamente.)
Nota: Você não precisa configurar um novo servidor web para isso. Você pode adicionar isso a um servidor web pré-existente, desde que a configuração não exista.
Nota: Isso pode ser bastante complicado. Você pode querer se concentrar em fazer isso funcionar no caso mais simples e, depois de funcionar e testado, fazê-lo funcionar em 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 um cibercafé). 3. ENTÃO máquinas fora da rede, sem VPN ativa 4. ENTÃO teste isso para outros sistemas operacionais
Neste exemplo, assumiremos que existe um servidor web acessível no mesmo endereço IP, esteja você dentro ou fora da empresa.
Em nosso "vá.corporação.example.com", isso significa que o "go" está em um subdomínio que só é acessível a pessoas internas e requer uma VPN para usar o serviço ShortName. Como o Google Apps geralmente é configurado para funcionar sem VPN (porque todo o acesso é HTTPS), isso não é o ideal.
Em nosso "vá.ramal.example.com", isso significa que o subdomínio é acessível tanto dentro quanto fora da empresa, e o A
registro aponta para um endereço IP externo.
Etapa 4: adicione 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 (go.ramal.example.com) é um A
registro que aponta para o endereço IP do novo servidor web que você está configurando.
O terceiro registro DNS (go-redirector) serve para ajudá-lo na depuração.
Etapa 5: configurar o servidor 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.com
deve funcionar neste momento.
Não prossiga 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 execute 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 de ".")
Alternativamente, você pode usar um caminho de pesquisa como:
corp.example.com example.com .
Mas isso adicionará uma pesquisa de DNS adicional para CADA página da web que visitarmos. Como eles falharão 99% das vezes, isso tornará a navegação na web mais lenta.
Em estações de trabalho e laptops, você precisa ter certeza de que o subdomínio está incluído no caminho de pesquisa do DNS. Dessa forma, quando o usuário digitar “go”, o software o encontrará no domínio.
Queremos configurar o caminho de pesquisa da máquina para incluir este subdomínio de todas as maneiras que o caminho de pesquisa possa ser definido:
Originalmente, o caminho de pesquisa do DNS não podia ser definido via DHCP. Este é um recurso adicionado recentemente e nem todos os clientes DHCP o suportam. Mesmo os clientes DHCP que o suportam precisam ser modificados porque quando um laptop está (por exemplo) em um cibercafé, ele está se comunicando 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 há 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 DNS em todos estes locais:
- 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é-anexar o
corp.example.com
domínio ao seu caminho de pesquisa se o servidor DHCP ainda não o tiver incluído.
Abaixo estão 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
PENDÊNCIA
- Instruções ISC DHCP
Se o caminho de pesquisa for apenas o domínio em que a máquina deveria estar, então:
option domain-name "corp.example.com";
Se os clientes suportarem RFC 3397 para fornecer um caminho de pesquisa, você poderá 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 um array de registros, onde o registro contém um array de outro registro, então você deve usar uma string 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 dnsmasq DHCP
PENDÊNCIA
Configurando máquinas configuradas estaticamente:
- janelas
PENDÊNCIA
- Linux/Unix
Edite /etc/resolv.conf
e certifique-se de que (1) "domain corp.example.com" seja a primeira linha, (2) adicione/edite a linha "search" para incluir o corp.example.com
domínio, (3) adicione uma linha "options ndotes:2" para reduza a carga em seus servidores DNS.
domain corp.example.com
search corp.example.com exmaple.com
options ndots:2
Configurando clientes DHCP para funcionarem em outros servidores DHCP
TODO preencher para Windows, Linux, etc.
Etapa 7: Teste, teste, teste!
Agora os usuários devem ser capazes de especificar:
http://go/foo http://go.example/foo http://go.example.com/foo
Na verdade, como teste de confiança, você desejará 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 por último, um conselho: mesmo que você tenha feito um trabalho perfeito, você ainda corre o risco de um http://go/foo
link não funcionar quando uma pessoa tentar 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 outros para sempre especificá-lo dessa forma.
Ou pelo menos codifique-os em HTML para que "go" fique visível no texto do link, mas o HREF real vá para o FQDN:
<a href="http://go.example.com/lunch">go/lunch</a>
Ensinar as pessoas do departamento de RP a fazer isso pode ser difícil. Você pode apenas dizer a eles que eles precisam usar a versão longa ( go.example.com
) em qualquer coisa que escreverem, porque o curto "ir/almoço" só funciona por acidente.
Etapa 8: HTTPS
TODO: Descubra como fazer com HTTPS (as certificações serão muito difíceis, senão impossíveis, de acertar).
Responder1
Esta questão deve ser marcada como “respondida” de uma forma ou de outra. Desta forma, ohttps://serverfault.com/unansweredO URL permanecerá correto. Por favor (poste e) aceite uma "resposta" para esta pergunta. Obrigado!
Minha "resposta" seria que construir (ou instalar) um serviço de encurtamento de links é muito fácil e, em vez de passar por todos os obstáculos acima, basta configurar um encurtador de links local em um servidor web que responda para "ir". example.com" e certifique-se de que seu DNS responda à pesquisa example.com. Dessa forma, você não vaza URLs internos para o mundo. (Possivelmente estou perdendo o foco.)
Alternativas:
Para uma empresa ou grupo de trabalho muito pequeno, pergunte a todos quais são os marcadores favoritos e encontre algum espaço para colocá-los na página inicial da intranet.
Como alternativa, implemente a Intranet para sua pequena empresa ou grupo como um wiki, com uma lista útil de links compartilhados para ajudar as pessoas a chegarem aonde provavelmente desejam.
Felicidades, -danny