Il post sul blog " Un servizio 'tinyurl' per il tuo dominio " spiega come impostare un servizio ShortName per il tuo dominio utilizzando Google Apps. Ad esempio, se il tuo dominio è example.come utilizzi Google Apps, puoi configurarlo in modo che http://go.example.comsia il servizio personale ShortName della tua azienda.
NOTA: non si tratta di creare un servizio "tinyurl" che il mondo possa usare. Questo è per un'impresa.
È utile disporre di un servizio con nome breve che solo gli utenti possano utilizzare in modo da poter creare collegamenti a pagine interne. Invece di dire alla gente un URL lungo e difficile, puoi dire "Il menu del pranzo di oggi è su http://go.example.com/lunch ". Il post sul blog documenta alcuni dei vantaggi di consentire alle persone di creare i propri collegamenti. (La cosa più importante: non devono disturbarti a creare un nuovo link!)
Il problema
Il problema con il sistema è che l'URL è ancora piuttosto lungo. Le persone preferiscono digitare "go / lunch" nel loro browser Web e farlo funzionare. Purtroppo, Google Apps non può supportarlo a causa di un tecnicismo di funzionamento del protocollo HTTP. L'intestazione "Host:" in HTTP 1.1 elenca il dominio digitato dall'utente nel proprio browser Web, non l' FQDN . In altre parole, quando Google Apps riceve la richiesta HTTP per " http: // go / lunch " il server web riceve "go" come nome host. Poiché Google Apps fornisce questo servizio per molti domini, non può dire se lo desideri go.example.como go.some-other-example.com.
Di conseguenza, gli utenti devono digitare "go.example.com/lunch" ogni volta, che è molto più lungo di "go / lunch".
La soluzione
Google potrebbe risolvere questo problema utilizzando i cookie Web o altri schemi. Nessuno dei quali è particolarmente pulito o facile. Fino a quando non lo farai, puoi risolvere il problema impostando una tua macchina che accetta le richieste come "go" e le reindirizza.
Il server accetta le richieste HTTP per un sito chiamato "go" e reindirizza la richiesta a go.example.com. Quindi creare i record DNS giusti affinché funzioni e modificare le configurazioni DHCP in modo che i laptop / le workstation facciano la cosa giusta.
Lo scopo di questo documento di errore del server è spiegare il processo, quindi fornire esempi di configurazione per aiutarti a farlo per il tuo sito. Dal momento che non ho accesso o conoscenza di tutti i sistemi operativi del mondo, sto trasformando questo in un "wiki della comunità" in modo che le persone possano compilare frammenti di configurazione mentre lo fanno funzionare per loro. Ho inserito "TODO" in un'area che necessita di miglioramenti.
I dettagli
In questo esempio useremo "example.com" come dominio.
Passaggio 1: configura il servizio Google Apps nel modo normale.
Configurare il servizio go.example.comcome di consueto. Provalo e assicurati che un URL come http://go.example.com/foofunziona. Non continuare se questo non è completo. Sarebbe come provare a riparare la tua auto prima di possederne una.
Passaggio 2: selezionare il nome host del redirector
Se il tuo servizio di shortname è go.example.com, idealmente dovresti creare il nome del tuo redirector go.example.com. Purtroppo, la fisica impedisce a due corpi di trovarsi nello stesso posto allo stesso tempo e DNS obbedisce alle leggi della fisica.
Il trucco è avere il redirector con lo stesso nome host del servizio ShortName, ma in un dominio diverso. Ad esempio, go.corp.example.com, go.ext.google.com, o go.this-is-different.example.com.
Le grandi aziende di solito hanno un sottodominio interno che non è esposto al mondo esterno. Di solito sono host interni INSIDEHOST.corp.google.com. Ecco dove metti il redirector.
Alcune aziende assegnano un sottodominio pieno di CNAME che puntano a servizi a cui è necessario accedere sia all'interno che all'esterno dell'azienda. In questo modo c'è un sottodominio che deve essere inserito nel percorso di ricerca DNS delle persone. (Le persone Unix possono pensare a questa come /usr/local/binuna sottodirectory piena di collegamenti simbolici) Tradizionalmente questo sottodominio è ext.example.com. In questo sottodominio sono CNAME come mail.ext.example.com, calendar.ext.example.com, vpn.ext.example.come così via.)
Avviso: l'aggiunta di un altro elemento al percorso di ricerca DNS è un altro modo per rallentare l'esecuzione dei computer. Effettuare una query DNS aggiuntiva OGNI TEMPO è lento e la navigazione sul Web sarà notevolmente più lenta. È molto meglio aggiungere questo redirector a un sottodominio che si trova già nel percorso di ricerca DNS della macchina, anche se ciò significa aggiungere un CNAME in più sottodomini. Ad esempio, se le tue macchine interne e le macchine connesse alla tua VPN hanno già corp.example.comnel loro percorso di ricerca, aggiungi lì il CNAME. Se desideri che macchine esterne non VPN in grado di accedere al redirector, potrebbe essere strano codificare corp.example.comnel loro percorso di ricerca se quello è il sottodominio per macchine a cui non è mai stato possibile accedere dall'esterno. In tal caso, un altro CNAME può essere aggiunto a un sottodominio esterno (comeext.example.com) per indicare il redirector. Aggiorna la configurazione del server Web per supportare entrambi.
Per questo esempio, supponiamo che tu abbia selezionato il redirector go.ext.example.com. La macchina può essere chiamata come vuoi, faremo tutta la magia nel DNS e nella configurazione del web server.
Passaggio 3: pianificazione per il redirector
Il server Web che si intende configurare può trovarsi su un server Web esistente o su uno nuovo creato appositamente per questo scopo. La chiave è che la macchina deve essere accessibile ovunque tu voglia che il servizio ShortName funzioni: all'interno dell'azienda, all'esterno dell'azienda, quando l'utente è connesso tramite VPN. (È possibile scegliere di rinunciare a far funzionare queste attività all'esterno dell'azienda per motivi di sicurezza. È inoltre possibile, per motivi di sicurezza, installare una macchina all'interno e un'altra all'esterno.)
Nota: non è necessario configurare un nuovo server Web per questo. Puoi aggiungerlo a un server Web preesistente purché la configurazione non esista.
Nota: questo può essere piuttosto complicato. Potresti voler concentrarti su come farlo funzionare nel caso più semplice, quindi una volta funzionato e testato, fallo funzionare per altre situazioni. In particolare, farlo funzionare in questo ordine: 1. workstation / laptop all'interno dell'azienda 2. POI macchine connesse tramite VPN, quindi macchine esterne all'azienda (ad esempio, in un Internet café). 3. ALLORA macchine esterne alla rete, senza VPN attiva 4. ALLORA test questo per altri sistemi operativi
In questo esempio, supponiamo che esista un server Web accessibile allo stesso indirizzo IP all'interno o all'esterno dell'azienda.
Nel nostro esempio "go. Corp .example.com", ciò significa che "go" si trova in un sottodominio accessibile solo agli addetti ai lavori e richiede una VPN per utilizzare il servizio ShortName. Poiché Google Apps è in genere configurato per funzionare senza VPN (poiché tutto l'accesso è HTTPS), questo non è ottimale.
Nel nostro esempio "go. Ext .example.com", ciò significa che il sottodominio è accessibile sia dall'interno che dall'esterno dell'azienda e che il Arecord punta a un indirizzo IP esterno.
Passaggio 4: aggiungere i record DNS per il redirector
Ecco i record DNS richiesti:
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
Il primo record DNS (go.example.com) dovrebbe già esistere come parte del passaggio 1.
Il secondo record DNS (vai. Ext .example.com) è un Arecord che punta all'indirizzo IP del nuovo server Web che si sta configurando.
Il terzo record DNS (go-redirector) è di aiuto durante il debug.
Passaggio 5: configurare il server Web
Aggiungi il reindirizzamento al server web. (Ciò presuppone che il server Web sia già installato e in esecuzione).
Ecco lo snippet di configurazione di 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>
Come testarlo. http://go-redirector.example.comdovrebbe funzionare a questo punto.
Non procedere fino a quando questo test non funziona. Piccoli passi.
Passaggio 6: configurare il percorso di ricerca DNS del client
Ora configureremo le macchine (tutto ciò che esegue un browser Web) in modo che il percorso di ricerca DNS includa "ext.example.com"
Sul server DHCP e sul server VPN inviare un percorso di ricerca DNS che sia:
corp.example.com.
(il sottodominio con l'host di reindirizzamento, seguito da ".")
In alternativa puoi usare un percorso di ricerca come:
corp.example.com example.com.
Tuttavia, ciò aggiungerà una ricerca DNS aggiuntiva per OGNI maledetta pagina web a cui andremo. Dal momento che falliranno il 99% delle volte, questo rallenterà la navigazione sul web.
Su workstation e laptop è necessario assicurarsi che il sottodominio sia incluso nel percorso di ricerca DNS. In questo modo quando l'utente digita "go", il software lo troverà nel dominio.
Vogliamo configurare il percorso di ricerca della macchina per includere questo sottodominio in tutti i modi in cui è possibile impostare il percorso di ricerca:
Inizialmente il percorso di ricerca DNS non poteva essere impostato tramite DHCP. Questa è una funzionalità appena aggiunta e non tutti i client DHCP la supportano. Anche i client DHCP che lo supportano devono essere modificati perché quando un laptop si trova (ad esempio) in un Internet café, sta parlando con un server DHCP che non si controlla. Quando un laptop utilizza una VPN, il software client VPN in realtà non utilizza DHCP ma in genere esiste un modo in cui il server VPN trasmette le impostazioni che si ottengono normalmente da un server DHCP.
Pertanto, si desidera impostare il percorso di ricerca DNS in tutti questi luoghi:
- Il server DHCP dovrebbe inviare le opzioni del percorso di ricerca DNS
- Le macchine configurate staticamente devono avere il percorso di ricerca DNS impostato
- I client che utilizzano DHCP devono essere configurati per precedere il
corp.example.comdominio al loro percorso di ricerca se il server DHCP non lo ha già incluso.
Di seguito sono riportate le istruzioni su come eseguire questa operazione su vari server DHCP e sistemi operativi.
Configurazione dei server DHCP per includere un percorso di ricerca DNS:
- Istruzioni DHCP di Windows
FARE
- Istruzioni DHCP ISC
Se il percorso di ricerca è solo il dominio in cui dovrebbe trovarsi la macchina, allora:
option domain-name "corp.example.com";
Se i client supportano RFC 3397 per fornire un percorso di ricerca, è possibile farlo, ma è scomodo in quanto non esiste un supporto nativo per un tipo di dati che è una sequenza di host DNS, ciascuno codificato come etichette con prefisso di lunghezza come in DNS. Non c'è modo di scrivere i valori di un'opzione definita come una matrice di record, in cui il record contiene una matrice di un altro record, quindi stai usando una stringa di dati per codificare le cose 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)
);
che dovrebbe (non testato) generare un elenco di ricerca di due elementi.
- dnsmasq istruzioni DHCP
FARE
Configurazione di macchine configurate staticamente:
- finestre
FARE
- Linux / Unix
Modifica /etc/resolv.confe assicurati che (1) il "dominio corp.example.com" sia la prima riga, (2) aggiungi / modifica la riga "cerca" per includere il corp.example.comdominio, (3) aggiungi una riga "opzioni ndotes: 2" a ridurre il carico sui server DNS.
domain corp.example.com
search corp.example.com exmaple.com
options ndots:2
Configurazione dei client DHCP per il funzionamento su altri server DHCP
TODO compilare per Windows, Linux, ecc.
Passaggio 7: test, test, test!
Ora gli utenti dovrebbero essere in grado di specificare:
http: // go / foo http: //go.example/foo http://go.example.com/foo
Infatti, come test di confidenza, ti consigliamo di testare quegli URL in tutte le situazioni:
( each OS you support ) * ( internal LAN / at an Internet cafe / while on the VPN )
Passaggio 8: altri consigli
E, infine, un piccolo consiglio: anche se avessi fatto un lavoro perfetto di questo, sei ancora a rischio che un http://go/foocollegamento non funzioni quando una persona tenta di digitarlo su un computer che non hai configurato per forzare la ricerca DNS percorso per includere il tuo dominio. Si dovrebbe, quindi, pubblicare link utilizzando l'URL completo: http://go.example.com/foo; e prenditi il tempo necessario per educare il dipartimento PR della tua azienda e gli altri a specificarlo sempre in questo modo.
O almeno codificali in HTML in modo che "go" sia visibile nel testo del link, ma l'effettivo HREF passa al nome di dominio completo:
<a href="http://go.example.com/lunch">go/lunch</a>
Insegnare alle persone del dipartimento PR a farlo potrebbe essere difficile. Potresti semplicemente dire loro che devono usare la versione lunga ( go.example.com) in tutto ciò che scrivono perché il breve "go / lunch" funziona solo per caso.
Passaggio 8: HTTPS
TODO: scopri come interagire con HTTPS (le certificazioni saranno molto difficili, se non impossibili, da ottenere).