FQDN이 필요하지 않도록 도메인에 Google ShortName 서비스를 설정하는 방법


13

블로그 게시물 " 도메인에 대한 'tinyurl'서비스 '는 Google Apps를 사용하여 도메인에 대한 ShortName 서비스를 설정하는 방법을 설명합니다. 예를 들어 도메인이 example.com있고 Google Apps를 사용하는 http://go.example.com경우 기업의 개인 ShortName 서비스가 되도록 도메인 을 구성 할 수 있습니다 .

참고 : 이것은 전세계에서 사용할 "tinyurl"서비스를 만드는 것이 아닙니다. 이것은 기업을위한 것입니다.

내부 페이지에 대한 링크를 만들 수 있도록 사용자 만 사용할 수있는 짧은 이름 서비스를 사용하는 것이 좋습니다. 사람들에게 길고 어려운 URL을 알려주는 대신 "오늘의 점심 메뉴는 http://go.example.com/lunch "에 있습니다. 블로그 게시물은 사람들이 자신의 링크를 설정할 수있게함으로써 얻을 수있는 이점 중 일부를 설명합니다. (가장 중요한 것은 새 링크를 설정하기 위해 귀찮게 할 필요가 없습니다!)

문제

시스템의 문제점은 URL이 여전히 길다는 것입니다. 사람들은 오히려 웹 브라우저에 "go / lunch"를 입력하여 작동하게합니다. 안타깝게도 Google Apps는 HTTP 프로토콜의 작동 방식에 대한 기술 때문에이를 지원할 수 없습니다. HTTP 1.1의 "Host :"헤더는 사용자가 FQDN이 아닌 웹 브라우저에 입력 한 도메인을 나열합니다 . 즉, Google Apps가 " http : // go / lunch "에 대한 HTTP 요청을 받으면 웹 서버는 호스트 이름으로 "go"를받습니다. Google Apps에 많은 도메인이 서비스를 제공하고 있기 때문에 당신이 원한다면, 그것은 말할 수 없다 go.example.comgo.some-other-example.com.

결과적으로 사용자는 "go / lunch"보다 훨씬 긴 "go.example.com/lunch"를 매번 입력해야합니다.

해결책

Google은 웹 쿠키 또는 다른 체계를 사용하여이 문제를 해결할 수 있습니다. 특히 깨끗하거나 쉬운 것은 없습니다. 그들이 할 때까지 요청을 "go"로 수락하고 리디렉션하는 자신의 컴퓨터를 설정하여 문제를 해결할 수 있습니다.

서버는 "go"라는 사이트에 대한 HTTP 요청을 수락하고 요청을로 리디렉션합니다 go.example.com. 그런 다음 제대로 작동하도록 올바른 DNS 레코드를 만들고 랩톱 / 워크 스테이션이 올바르게 작동하도록 DHCP 구성을 돌리십시오.

이 서버 결함 문서의 요점은 프로세스를 설명하고 사이트에이를 수행하는 데 도움이되는 구성 예제를 제공하는 것입니다. 전 세계의 모든 운영 체제에 대한 액세스 권한이나 지식이 없기 때문에 사람들이 구성 스 니펫을 작성하여 작업 할 수 있도록이를 "커뮤니티 위키"로 만들고 있습니다. 특히 개선이 필요한 영역에 'TODO'를 넣었습니다.

세부 사항

이 예에서는 "example.com"을 도메인으로 사용합니다.

1 단계 : 일반적인 방식으로 Google Apps 서비스를 설정합니다.

서비스를 go.example.com정상적으로 구성하십시오 . 그것을 테스트하고 URL이 http://go.example.com/foo작동 하는지 확인하십시오 . 이것이 완료되지 않으면 계속하지 마십시오. 자동차를 소유하기 전에 수리하려고하는 것과 같습니다.

2 단계 : 리디렉터 호스트 이름 선택

짧은 이름 서비스가 인 go.example.com경우 이상적으로 리디렉터 이름을 지정 go.example.com합니다. 안타깝게도 물리는 두 몸이 동시에 같은 장소에 있지 못하도록하고 DNS는 물리 법칙을 따릅니다.

트릭은 리디렉터가 ShortName 서비스와 동일한 호스트 이름이지만 다른 도메인에 있도록하는 것입니다. 예를 들어 go.corp.example.com, go.ext.google.com또는 go.this-is-different.example.com.

대기업에는 일반적으로 외부 세계에 노출되지 않는 내부 하위 도메인이 있습니다. 일반적으로 내부 호스트는 INSIDEHOST.corp.google.com입니다. 리디렉터를 넣는 곳입니다.

일부 회사는 회사 내부와 외부에서 액세스해야하는 서비스를 가리키는 CNAME으로 가득 찬 하위 도메인을 할당합니다. 그렇게하면 사람들의 DNS 검색 경로에 하나의 하위 도메인이 있어야합니다. (유닉스 사람들은 이것을 /usr/local/bin심볼릭 링크로 가득 찬 서브 디렉토리 라고 생각할 수 있습니다 ) 전통적으로이 서브 도메인은 ext.example.com입니다. 하위 도메인에 CNAME이는 같다 mail.ext.example.com, calendar.ext.example.com, vpn.ext.example.com, 등.)

경고 : DNS 검색 경로에 다른 항목을 추가하면 컴퓨터 속도가 느려지는 또 다른 방법입니다. 매번 추가 DNS 쿼리를 수행하면 속도가 느리고 웹 서핑 속도가 현저하게 느려집니다. 여러 하위 도메인에 CNAME을 추가하더라도 시스템의 DNS 검색 경로에 이미있는 하위 도메인에이 리디렉터를 추가하는 것이 훨씬 좋습니다. 예를 들어 VPN에 연결된 내부 시스템과 시스템이 corp.example.com이미 검색 경로에있는 경우 여기에 CNAME을 추가하십시오. VPN을 사용하지 않는 외부 컴퓨터가 리디렉터에 액세스 할 수 있도록 corp.example.com하려면 외부에서 액세스하지 않는 컴퓨터의 하위 도메인 인 경우 검색 경로 에 하드 코딩하는 것이 이상 할 수 있습니다 . 이 경우 다른 CNAME을 외부 하위 도메인에 추가 할 수 있습니다 (예 :ext.example.com)를 사용하여 리디렉터를 가리 킵니다. 두 가지를 모두 지원하도록 웹 서버 구성을 업데이트하십시오.

이 예에서는 리디렉터가로 선택되었다고 가정합니다 go.ext.example.com. 머신은 원하는대로 호출 할 수 있으며, DNS 및 웹 서버 구성에서 모든 마법을 수행합니다.

3 단계 : 리디렉터 계획

설정하려는 웹 서버는 기존 웹 서버 또는이 용도로만 구축 된 새 웹 서버에있을 수 있습니다. 핵심은 사용자가 VPN을 통해 연결되어있을 때 회사 내부, 회사 외부에서 ShortName 서비스를 작동하려는 어느 곳에서나 컴퓨터에 액세스 할 수 있어야한다는 것입니다. (보안상의 이유로 회사 외부에서이 작업을 수행하지 않을 수도 있습니다. 또한 보안상의 이유로 한 시스템을 내부와 외부에 설정할 수 있습니다.)

참고 :이를 위해 새 웹 서버를 설정할 필요가 없습니다. 구성이 존재하지 않는 한 기존 웹 서버에 추가 할 수 있습니다.

참고 : 이것은 다소 복잡 할 수 있습니다. 가장 간단한 경우에이 작업을 수행하는 데 중점을 두었다가 한 번 작업하고 테스트 한 후 다른 상황에서도 작동하도록 할 수 있습니다. 1. 회사 내부의 워크 스테이션 / 노트북 2. VPN으로 연결된 컴퓨터와 회사 외부 컴퓨터 (예 : 인터넷 카페). 3. VPN을 사용하지 않고 네트워크 외부에있는 머신 4. 다른 운영 체제에 대해이를 테스트합니다.

이 예에서는 회사 내부 또는 외부에서 동일한 IP 주소로 액세스 할 수있는 웹 서버가 있다고 가정합니다.

"go. corp .example.com"예에서 "go"는 내부자 만 액세스 할 수있는 하위 도메인에 있으며 ShortName 서비스를 사용하려면 VPN이 필요합니다. Google Apps는 일반적으로 VPN없이 작동하도록 구성되어 있기 때문에 (모든 액세스가 HTTPS이기 때문에) 최적이 아닙니다.

"go. ext .example.com"예제에서 이는 회사 내부와 외부에서 하위 도메인에 액세스 할 수 있으며 A레코드가 외부 IP 주소를 가리킴을 의미합니다.

4 단계 : 리디렉터에 대한 DNS 레코드 추가

필요한 DNS 레코드는 다음과 같습니다.

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

첫 번째 DNS 레코드 (go.example.com)는 1 단계의 일부로 이미 존재해야합니다.

두 번째 DNS 레코드 (go. ext .example.com)는 A구성중인 새 웹 서버의 IP 주소를 가리키는 레코드입니다.

세 번째 DNS 레코드 (go-redirector)는 디버깅 할 때 도움이됩니다.

5 단계 : 웹 서버 구성

웹 서버에 리디렉션을 추가하십시오. (이것은 웹 서버가 이미 설치되어 실행 중이라고 가정합니다).

다음은 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>

이것을 테스트하는 방법. http://go-redirector.example.com이 시점에서 작동합니다.

이 테스트가 작동 할 때까지 진행하지 마십시오. 걸음마.

6 단계 : 클라이언트의 DNS 검색 경로 구성

이제 DNS 검색 경로에 "ext.example.com"이 포함되도록 머신 (웹 브라우저를 실행하는 모든 것)을 구성하려고합니다.

DHCP 서버와 VPN 서버에서 다음과 같은 DNS 검색 경로를 보냅니다.

corp.example.com.

(리디렉션 호스트가있는 하위 도메인 다음에 ".")

또는 다음과 같은 검색 경로를 사용할 수 있습니다.

corp.example.com example.com.

그러나 이것은 우리가가는 모든 웹 페이지에 대한 추가 DNS 조회를 추가 할 것입니다. 99 %의 시간이 걸리기 때문에 웹 서핑 속도가 느려질 것입니다.

워크 스테이션 및 랩톱에서 하위 도메인이 DNS 검색 경로에 포함되어 있는지 확인해야합니다. 이렇게하면 사용자가 "go"를 입력하면 소프트웨어가 도메인에서 찾을 수 있습니다.

검색 경로를 설정할 수있는 모든 방법으로이 하위 도메인을 포함하도록 머신의 검색 경로를 구성하려고합니다.

원래 DNS 검색 경로는 DHCP를 통해 설정할 수 없습니다. 이것은 새로 추가 된 기능이며 모든 DHCP 클라이언트가 지원하지는 않습니다. 랩톱이 인터넷 카페에있을 때 사용자가 제어하지 않는 DHCP 서버와 통신하기 때문에이를 지원하는 DHCP 클라이언트도 수정해야합니다. 랩톱에서 VPN을 사용하는 경우 VPN 클라이언트 소프트웨어는 실제로 DHCP를 사용하지 않지만 일반적으로 VPN 서버가 DHCP 서버에서 가져 오는 설정을 전송하는 방법이 있습니다.

따라서이 모든 위치에서 DNS 검색 경로를 설정하려고합니다.

  • DHCP 서버는 DNS 검색 경로 옵션을 보내야합니다
  • 정적으로 구성된 머신에는 DNS 검색 경로가 설정되어 있어야합니다.
  • DHCP를 사용하는 클라이언트 corp.example.com는 DHCP 서버에 도메인이 포함되어 있지 않은 경우 검색 경로에 도메인 을 미리 추가하도록 구성해야합니다 .

다음은 다양한 DHCP 서버 및 운영 체제에서이를 수행하는 방법에 대한 지침입니다.

DNS 검색 경로를 포함하도록 DHCP 서버 구성 :

  1. Windows DHCP 지침

할 것

  1. ISC DHCP 지침

검색 경로가 기계가 있어야하는 도메인 인 경우 다음을 수행하십시오.

option domain-name "corp.example.com";

클라이언트가 검색 경로를 제공하기 위해 RFC 3397을 지원하는 경우이 작업을 수행 할 수 있지만 DNS 호스트 시퀀스와 같은 데이터 유형에 대한 기본 지원이 없으므로 각 유형은 DNS에서와 같이 길이 접두사 레이블로 인코딩됩니다. 레코드가 다른 레코드의 배열을 포함하는 레코드 배열로 정의 된 옵션의 값을 쓸 수있는 방법이 없으므로 데이터 문자열을 사용하여 수동으로 인코딩해야합니다.

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)
    );

두 항목 검색 목록을 생성해야합니다.

  1. dnsmasq DHCP 지침

할 것

정적으로 구성된 머신 구성 :

  1. 윈도우

할 것

  1. 리눅스 / 유닉스

편집 /etc/resolv.conf및 확인 (1) "도메인 corp.example.com"첫 번째 줄은, (2) 추가 / 편집 "검색"줄을 포함 할 수 있도록 corp.example.com추가 도메인, (3) "옵션 ndotes : 2"라인 DNS 서버의 부하를 줄입니다.

domain corp.example.com
search corp.example.com exmaple.com
options ndots:2

다른 DHCP 서버에서 작동하도록 DHCP 클라이언트 구성

Windows, Linux 등을위한 TODO 작성

7 단계 : 테스트, 테스트, 테스트!

이제 사용자는 다음을 지정할 수 있어야합니다.

http : // go / foo http : //go.example/foo http://go.example.com/foo

실제로 신뢰 테스트로서 모든 상황에서 해당 URL을 테스트하려고합니다.

( each OS you support ) * ( internal LAN / at an Internet cafe / while on the VPN )

8 단계 : 기타 조언

그리고 마지막으로, 약간의 조언 :이 작업을 완벽하게 수행 했더라도 http://go/fooDNS 검색을 강제로 구성하지 않은 컴퓨터에서 사람이 입력하려고하면 링크가 작동하지 않을 위험이 있습니다. 도메인을 포함 할 경로입니다. 따라서 전체 URL을 사용하여 링크를 게시해야합니다. http://go.example.com/foo; 시간을내어 회사의 PR 부서와 다른 사람들에게 항상 그렇게 지정하도록 교육하십시오.

또는 최소한 링크 텍스트에 "go"가 표시되도록 HTML로 인코딩하지만 실제 HREF는 FQDN으로 이동합니다.

<a href="http://go.example.com/lunch">go/lunch</a>

이를 위해 PR 부서 직원들을 가르치는 것은 어려울 수 있습니다. go.example.com짧은 "go / lunch"는 우연히 만 작동하기 때문에 그들이 작성하는 모든 것에서 긴 버전 ( ) 을 사용해야한다고 말할 수도 있습니다 .

8 단계 : HTTPS

TODO : HTTPS를 사용하여 작업하는 방법을 익히십시오 (인증은 불가능하지는 않지만 매우 어렵습니다).


2
클라이언트가 특정 검색 경로를 사용하도록 설정해야하는 경우 절대로 비행하지 않습니다. 정말로 이것을 원한다면, 짧은 TLD를 구입하십시오 – 단 $ 280k의 가격
Alnitak

1
공공 서비스가 아닌 엔터프라이즈 사용자를위한 것이라고 설명해야합니다.
TomOnTime

6
안녕 톰, 일반적으로 귀하의 질문에 제안하는 것은 질문을 한 다음 답변으로 답변을 게시하는 것입니다. 이 upvoted 얻을 수있는 허용 된 것으로 표시 그런 식 : serverfault.com/faq은 (하십시오 question.`의 형태로 문구를`는 질문하고 자신의 질문에 대답,하지만 당신은 제 퍼디에 척 완벽하게 잘이기도합니다)
Mark Henderson

1
그리고 ... Tom은 이제 "의문의 여지가 없으며 serverfault meme에 속하지 않습니다"라고 소개되었습니다. 워터 쿨러에 오신 것을 환영합니다. 멋진 포스트 톰. +1.
Joseph Kern

2
@TomOnTime 어쩌면 질문과 답변에서 "문제"와 "솔루션"을 나눌 수 있습니다. 그것은 모두를 행복하게 할 것입니다! 감사합니다!
splattne

답변:


3

이 질문은 어떤 방식 으로든 "답변"으로 표시되어야합니다. 이런 식으로 /server//unanswered URL은 그대로 유지됩니다. 이 질문에 대한 "답변"을 게시하십시오. 감사!

저의 "답변"은 링크 단축 서비스를 구축 (또는 설치)하는 것이 매우 쉬울 것이며, 위의 모든 과정을 뛰어 넘기보다는 웹 서버에 "go. example.com '으로 이동하여 DNS가 example.com 검색에 응답하는지 확인하십시오. 이런 식으로 내부 URL을 전세계로 유출하지 않습니다. (아마도 요점을 놓치고 있습니다.)

대안 :

  • 소규모 회사 나 작업 그룹의 경우 모든 사람에게 즐겨 찾는 책갈피를 요청하고 인트라넷 첫 페이지에 배치 할 공간을 찾으십시오.

  • 또는 소규모 회사 또는 그룹의 인트라넷을 위키로 배포하고 사람들이 가고 싶은 곳을 쉽게 찾을 수 있도록 편리한 공유 핫 링크 목록을 제공합니다.

건배, -danny

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.