Posting blog " Layanan 'tinyurl' untuk domain Anda " menjelaskan cara menyiapkan layanan ShortName untuk domain Anda menggunakan Google Apps. Misalnya, jika domain example.comAnda dan Anda menggunakan Google Apps, Anda dapat mengonfigurasinya sehingga http://go.example.commerupakan layanan ShortName pribadi perusahaan Anda.
CATATAN: Ini bukan tentang menciptakan layanan "tinyurl" untuk digunakan dunia. Ini untuk perusahaan.
Berguna untuk memiliki layanan nama pendek yang hanya dapat digunakan oleh pengguna Anda sehingga Anda dapat membuat tautan ke halaman internal. Daripada memberi tahu orang-orang URL yang panjang dan sulit, Anda dapat mengatakan, "Menu makan siang hari ini ada di http://go.example.com/lunch ". Posting blog mendokumentasikan beberapa manfaat memberdayakan orang untuk mengatur tautan mereka sendiri. (Paling penting: mereka tidak perlu repot ANDA untuk membuat tautan baru!)
Masalah
Masalah dengan sistem adalah bahwa URL masih agak panjang. Orang lebih suka mengetik "pergi / makan siang" ke dalam browser web mereka dan membuatnya bekerja. Sayangnya, Google Apps tidak dapat mendukung ini karena teknis cara kerja protokol HTTP. Header "Host:" di HTTP 1.1 mencantumkan domain yang diketik pengguna ke browser web mereka, bukan FQDN . Dengan kata lain, ketika Google Apps mendapatkan permintaan HTTP untuk " http: // go / lunch " server web menerima "go" sebagai nama host. Karena Google Apps menyediakan layanan ini untuk banyak domain, ia tidak dapat menentukan apakah Anda mau go.example.comatau go.some-other-example.com.
Akibatnya, pengguna harus mengetik "go.example.com/lunch" setiap kali, yang jauh lebih lama daripada "pergi / makan siang".
Solusinya
Google dapat menyelesaikan ini dengan menggunakan cookie web atau skema lainnya. Tidak ada yang bersih atau mudah. Sampai mereka berhasil, Anda dapat menyelesaikan masalah dengan menyiapkan mesin Anda sendiri yang menerima permintaan sebagai "buka" dan mengarahkan ulang mereka.
Server menerima permintaan HTTP untuk situs yang disebut "go" dan mengalihkan permintaan ke go.example.com. Anda kemudian membuat catatan DNS yang tepat sehingga berfungsi, dan mengubah konfigurasi DHCP Anda sehingga laptop / workstation Anda melakukan hal yang benar.
Maksud dari dokumen Server Fault ini adalah untuk menjelaskan proses kemudian memberikan contoh konfigurasi untuk membantu Anda melakukan ini untuk situs Anda. Karena saya tidak memiliki akses atau pengetahuan tentang setiap sistem operasi di dunia, saya menjadikan ini sebagai "wiki komunitas" sehingga orang dapat mengisi potongan konfigurasi ketika mereka membuatnya bekerja untuk mereka. Saya telah memasukkan 'TODO' di bidang yang sangat membutuhkan perbaikan.
Rinciannya
Dalam contoh ini kita akan menggunakan "example.com" sebagai domain.
Langkah 1: Siapkan layanan Google Apps dengan cara biasa.
Konfigurasikan layanan go.example.comseperti biasa. Uji dan pastikan URL menyukai http://go.example.com/fookarya. Jangan melanjutkan jika ini tidak lengkap. Itu seperti mencoba memperbaiki mobil Anda sebelum Anda memilikinya.
Langkah 2: Pilih nama host redirector Anda
Jika layanan nama pendek Anda go.example.com, idealnya Anda akan membuat nama pengalih arah go.example.com. Sayangnya, fisika mencegah dua benda berada di tempat yang sama pada saat yang sama, dan DNS mematuhi hukum fisika.
Kuncinya adalah membuat redirector menjadi nama host yang sama dengan layanan ShortName, tetapi dalam domain yang berbeda. Sebagai contoh, go.corp.example.com, go.ext.google.com, atau go.this-is-different.example.com.
Perusahaan besar biasanya memiliki subdomain internal yang tidak terekspos ke dunia luar. Host internal biasanya INSIDEHOST.corp.google.com. Di situlah Anda meletakkan redirector.
Beberapa perusahaan mengalokasikan subdomain yang penuh dengan CNAME yang menunjuk ke layanan yang harus diakses dari dalam dan luar perusahaan. Dengan begitu ada satu subdomain yang perlu dimasukkan ke pencarian orang DNS. (Orang Unix dapat menganggap ini sebagai /usr/local/binsubdirektori yang penuh dengan symlink). Biasanya subdomain ini ext.example.com. Dalam subdomain yang CNAMEs seperti mail.ext.example.com, calendar.ext.example.com, vpn.ext.example.com, dan sebagainya.)
Peringatan: Menambahkan item lain ke jalur pencarian DNS Anda adalah cara lain untuk membuat komputer Anda berjalan lebih lambat. Melakukan kueri DNS tambahan SETIAP SAAT adalah lambat dan berselancar di web akan terasa lebih lambat. Jauh lebih baik untuk menambahkan pengalihan ini ke subdomain yang sudah ada di jalur pencarian DNS mesin Anda, bahkan jika ini berarti menambahkan CNAME di beberapa subdomain. Misalnya, jika mesin internal Anda dan mesin yang terhubung ke VPN Anda sudah ada corp.example.comdi jalur pencarian mereka, tambahkan CNAME di sana. Jika Anda ingin mesin-mesin eksternal yang tidak di-VPN-kan untuk dapat mengakses redirector, mungkin aneh untuk kode keras corp.example.comke jalur pencarian mereka jika itu adalah subdomain untuk mesin yang tidak pernah diakses dari luar. Dalam hal itu, CNAME lain dapat ditambahkan ke subdomain eksternal (sepertiext.example.com) untuk menunjuk ke redirector. Perbarui konfigurasi server web untuk mendukung keduanya.
Untuk contoh ini, mari kita asumsikan Anda telah memilih redirector go.ext.example.com. Mesin dapat disebut apa pun yang Anda inginkan, kami akan melakukan semua keajaiban dalam DNS dan konfigurasi server web.
Langkah 3: Merencanakan redirector Anda
Server web yang akan Anda siapkan bisa berada di server web yang ada atau yang baru dibangun hanya untuk tujuan ini. Kuncinya adalah bahwa mesin harus dapat diakses dari mana saja Anda ingin layanan ShortName berfungsi: di dalam perusahaan, di luar perusahaan, ketika pengguna terhubung melalui VPN. (Anda dapat memilih untuk tidak menjalankan ini dari luar perusahaan karena alasan keamanan. Anda juga dapat, karena alasan keamanan, memasang satu mesin di bagian dalam dan yang lain di luar.)
Catatan: Anda tidak perlu menyiapkan server web baru untuk ini. Anda dapat menambahkan ini ke server web yang sudah ada selama konfigurasi tidak ada.
Catatan: Ini bisa agak rumit. Anda mungkin ingin fokus untuk membuat ini berfungsi dalam kasus yang paling sederhana, kemudian setelah bekerja dan diuji, membuatnya bekerja untuk situasi lain. Secara khusus, membuatnya berfungsi dalam urutan ini: 1. workstation / laptop di dalam perusahaan 2. KEMUDIAN mesin terhubung dengan VPN, kemudian mesin di luar perusahaan (misalnya, di warnet). 3. KEMUDIAN mesin di luar jaringan, tanpa VPN naik 4. KEMUDIAN menguji ini untuk sistem operasi lain
Dalam contoh ini, kami akan menganggap ada server web yang dapat diakses di alamat IP yang sama baik Anda di dalam atau di luar perusahaan.
Dalam contoh "go. Corp .example.com" kami, ini berarti "go" berada dalam subdomain yang hanya dapat diakses oleh orang dalam, dan memerlukan VPN untuk menggunakan layanan ShortName. Karena Google Apps biasanya dikonfigurasikan untuk bekerja tanpa VPN (karena semua akses adalah HTTPS), ini tidak optimal.
Dalam contoh "go. Ext .example.com" kami, ini berarti subdomain dapat diakses dari dalam dan luar perusahaan, dan Acatatan menunjuk ke alamat IP eksternal.
Langkah 4: Tambahkan catatan DNS untuk pengalihan Anda
Berikut adalah data DNS yang diperlukan:
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
Data DNS pertama (go.example.com) harus sudah ada sebagai bagian dari Langkah 1.
Data DNS kedua (go. Ext .example.com) adalah Acatatan yang menunjuk pada alamat IP dari server web baru yang Anda konfigurasikan.
Catatan DNS ketiga (go-redirector) adalah untuk membantu Anda saat debugging.
Langkah 5: Konfigurasikan server web
Tambahkan pengalihan ke server web. (Ini mengasumsikan server web sudah diinstal dan berjalan).
Berikut ini cuplikan konfigurasi 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>
Cara mengujinya. http://go-redirector.example.comharus bekerja pada titik ini.
Jangan melanjutkan sampai tes ini berhasil. Langkah kecil.
Langkah 6: Konfigurasikan jalur pencarian DNS klien
Sekarang kita akan mengkonfigurasi mesin (apa pun yang menjalankan browser web) sehingga jalur pencarian DNS termasuk "ext.example.com"
Di server DHCP dan server VPN Anda mengirim jalur pencarian DNS yaitu:
corp.example.com.
(subdomain dengan host pengalihan, diikuti oleh ".")
Atau Anda dapat menggunakan jalur pencarian seperti:
corp.example.com example.com.
Namun itu akan menambah pencarian DNS tambahan untuk SETIAP halaman web yang kita kunjungi. Karena mereka akan gagal 99% dari waktu, itu hanya akan membuat web surfing lambat.
Di workstation dan laptop Anda perlu memastikan bahwa subdomain termasuk dalam jalur pencarian DNS mereka. Dengan begitu ketika pengguna mengetik "pergi", perangkat lunak akan menemukannya di domain.
Kami ingin mengonfigurasi jalur pencarian mesin untuk menyertakan subdomain ini dengan segala cara yang memungkinkan jalur pencarian dapat diatur:
Awalnya jalur pencarian DNS tidak dapat diatur melalui DHCP. Ini adalah fitur yang baru ditambahkan dan tidak semua klien DHCP mendukungnya. Bahkan klien DHCP yang mendukungnya perlu dimodifikasi karena ketika laptop di (misalnya) warnet, ia berbicara ke server DHCP yang tidak Anda kontrol. Ketika laptop menggunakan VPN, perangkat lunak klien VPN tidak benar-benar menggunakan DHCP tetapi biasanya ada beberapa cara server VPN mentransmisikan pengaturan yang biasanya didapat dari server DHCP.
Karena itu Anda ingin mengatur jalur pencarian DNS di semua tempat ini:
- Server DHCP harus mengirim opsi jalur pencarian DNS
- Mesin yang dikonfigurasi secara statis harus memiliki jalur pencarian DNS yang ditetapkan
- Klien yang menggunakan DHCP harus dikonfigurasi untuk pra-pend
corp.example.comdomain ke jalur pencarian mereka jika server DHCP belum memasukkannya.
Di bawah ini adalah petunjuk tentang cara melakukan ini di berbagai server DHCP dan sistem operasi.
Mengkonfigurasi server DHCP untuk menyertakan Jalur Pencarian DNS:
- Instruksi Windows DHCP
MELAKUKAN
- Petunjuk DHCP ISC
Jika jalur pencarian hanyalah domain tempat mesin itu berada, maka:
option domain-name "corp.example.com";
Jika klien mendukung RFC 3397 untuk menyediakan jalur pencarian, maka Anda dapat melakukan ini, tetapi ini canggung karena tidak ada dukungan asli untuk tipe data yang merupakan urutan host DNS, masing-masing dikodekan sebagai label awalan panjang seperti pada DNS. Tidak ada cara untuk menulis nilai-nilai opsi yang didefinisikan sebagai array catatan, di mana catatan berisi array dari catatan lain, jadi Anda harus menggunakan data-string untuk menyandikan sesuatu secara manual.
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)
);
yang seharusnya (belum diuji) menghasilkan daftar pencarian dua item.
- dnsmasq instruksi DHCP
MELAKUKAN
Mengkonfigurasi mesin yang dikonfigurasi secara statis:
- Windows
MELAKUKAN
- Linux / Unix
Edit /etc/resolv.confdan pastikan (1) "domain corp.example.com" adalah baris pertama, (2) tambahkan / edit baris "cari" untuk memasukkan corp.example.comdomain, (3) tambahkan baris "options ndotes: 2" ke mengurangi beban pada server DNS Anda.
domain corp.example.com
search corp.example.com exmaple.com
options ndots:2
Mengkonfigurasi klien DHCP agar berfungsi saat di server DHCP lainnya
Isi TODO untuk Windows, Linux, dll.
Langkah 7: Uji, uji, uji!
Sekarang pengguna harus dapat menentukan:
http: // go / foo http: //go.example/foo http://go.example.com/foo
Faktanya, sebagai tes kepercayaan, Anda ingin menguji URL-URL itu dalam semua situasi:
( each OS you support ) * ( internal LAN / at an Internet cafe / while on the VPN )
Langkah 8: Saran lainnya
Dan terakhir, satu saran: Sekalipun Anda telah melakukan pekerjaan dengan sempurna ini, Anda masih menghadapi risiko http://go/footautan tidak berfungsi ketika seseorang mencoba mengetiknya di komputer yang tidak Anda konfigurasi untuk memaksa pencarian DNS. jalur untuk memasukkan domain Anda. Anda harus, karena itu, mempublikasikan link menggunakan URL lengkap: http://go.example.com/foo; dan luangkan waktu untuk mendidik departemen PR perusahaan Anda dan orang lain untuk selalu menetapkannya seperti itu.
Atau setidaknya, enkode dalam HTML sehingga "go" terlihat di teks tautan, tetapi HREF yang sebenarnya pergi ke FQDN:
<a href="http://go.example.com/lunch">go/lunch</a>
Mengajari orang-orang di departemen PR untuk melakukan ini mungkin sulit. Anda mungkin hanya ingin memberi tahu mereka bahwa mereka harus menggunakan versi panjang ( go.example.com) dalam apa pun yang mereka tulis karena "go / lunch" singkat hanya bekerja secara tidak sengaja.
Langkah 8: HTTPS
TODO: Cari tahu bagaimana hubungannya dengan HTTPS (sertifikasi akan sangat sulit, jika bukan tidak mungkin, untuk mendapatkan yang benar).