블로그 게시물 "귀하의 도메인을 위한 'tinyurl' 서비스"에서는 Google Apps를 사용하여 도메인에 ShortName 서비스를 설정하는 방법을 설명합니다. 예를 들어 도메인이 Google Apps를 사용하는 경우 기업의 개인 ShortName 서비스가 example.com되도록 구성할 수 있습니다 .http://go.example.com
참고: 이것은 전 세계가 사용할 수 있는 "tinyurl" 서비스를 만드는 것이 아닙니다. 이것은 기업용입니다.
내부 페이지에 대한 링크를 만들 수 있도록 사용자만 사용할 수 있는 단축 이름 서비스를 보유하는 것이 유용합니다. 사람들에게 길고 어려운 URL을 알려주는 것보다 "오늘 점심 메뉴는http://go.example.com/lunch". 블로그 게시물에는 사람들이 자신의 링크를 설정할 수 있는 권한을 부여함으로써 얻을 수 있는 몇 가지 이점이 설명되어 있습니다. (가장 중요한 점: 새 링크를 설정하기 위해 귀하를 귀찮게 할 필요가 없다는 점입니다!)
문제
시스템의 문제는 URL이 여전히 다소 길다는 것입니다. 사람들은 웹 브라우저에 "go/lunch"를 입력하여 작동시키길 원합니다. 안타깝게도 Google Apps는 HTTP 프로토콜 작동 방식의 기술적 문제로 인해 이를 지원할 수 없습니다. HTTP 1.1의 "Host:" 헤더에는 사용자가 웹 브라우저에 입력한 도메인이 나열되어 있습니다.FQDN. 즉, Google Apps가 '에 대한 HTTP 요청을 받으면http://go/lunchgo.example.com" 웹 서버는 호스트 이름으로 "go"를 수신합니다. Google Apps는 많은 도메인에 이 서비스를 제공하기 때문에 사용자가 원하는지 또는 를 원하는지 알 수 없습니다 go.some-other-example.com.
결과적으로 사용자는 매번 'go.example.com/lunch'를 입력해야 하며 이는 'go/lunch'보다 훨씬 깁니다.
해결책
Google은 웹 쿠키나 다른 방식을 사용하여 이 문제를 해결할 수 있습니다. 어느 것 하나 특별히 깨끗하거나 쉬운 것은 없습니다. 그렇게 될 때까지 요청을 "이동"으로 받아들이고 리디렉션하는 자체 시스템을 설정하여 문제를 해결할 수 있습니다.
서버는 "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. 해당 하위 도메인에는 mail.ext.example.com, calendar.ext.example.com, vpn.ext.example.com등과 같은 CNAME이 있습니다.)
경고: DNS 검색 경로에 또 다른 항목을 추가하는 것은 컴퓨터 실행 속도를 느리게 만드는 또 다른 방법입니다. 매번 추가 DNS 쿼리를 수행하는 것은 느리고 웹 서핑도 눈에 띄게 느려집니다. 여러 하위 도메인에 CNAME을 추가해야 하는 경우에도 컴퓨터의 DNS 검색 경로에 이미 있는 하위 도메인에 이 리디렉터를 추가하는 것이 훨씬 좋습니다. 예를 들어 내부 컴퓨터와 VPN에 연결된 컴퓨터가 corp.example.com이미 검색 경로에 있는 경우 CNAME을 거기에 추가하세요. VPN으로 연결되지 않은 외부 시스템이 리디렉터에 액세스할 수 있도록 하려면 해당 corp.example.com검색 경로가 외부에서 액세스한 적이 없는 시스템의 하위 도메인인 경우 검색 경로에 하드 코딩하는 것이 이상할 수 있습니다. 이 경우 ext.example.com리디렉터를 가리키도록 다른 CNAME을 외부 하위 도메인(예: )에 추가할 수 있습니다. 두 가지를 모두 지원하도록 웹 서버 구성을 업데이트합니다.
이 예에서는 리디렉터가 로 선택되었다고 가정합니다 go.ext.example.com. 기계는 당신이 원하는 대로 불릴 수 있습니다. 우리는 DNS와 웹 서버 구성에서 모든 마법을 수행할 것입니다.
3단계: 리디렉터 계획
설정하려는 웹 서버는 기존 웹 서버에 있을 수도 있고 이 목적으로만 구축된 새 웹 서버에 있을 수도 있습니다. 핵심은 ShortName 서비스가 작동하기를 원하는 곳 어디에서나(사용자가 VPN을 통해 연결된 경우 회사 내부, 회사 외부) 어디에서나 시스템에 액세스할 수 있어야 한다는 것입니다. (보안상의 이유로 회사 외부에서 이 작업을 수행하지 않도록 선택할 수도 있습니다. 또한 보안상의 이유로 내부에 컴퓨터 하나를 설치하고 외부에 다른 컴퓨터를 설치할 수도 있습니다.)
참고: 이를 위해 새 웹 서버를 설정할 필요는 없습니다. 구성이 존재하지 않는 한 이를 기존 웹 서버에 추가할 수 있습니다.
참고: 이는 다소 복잡할 수 있습니다. 가장 간단한 경우에 이 작업을 수행하는 데 집중한 다음 작업 및 테스트를 마친 후에는 다른 상황에서도 작동하도록 할 수 있습니다. 특히 다음 순서로 작동하도록 하세요. 1. 회사 내부의 워크스테이션/노트북 2. 그런 다음 VPN으로 연결된 컴퓨터, 회사 외부의 컴퓨터(예: 인터넷 카페). 3. 그런 다음 VPN을 사용하지 않고 네트워크 외부의 컴퓨터를 사용합니다. 4. 그런 다음 다른 운영 체제에 대해 테스트합니다.
이 예에서는 회사 내부에 있든 외부에 있든 동일한 IP 주소로 액세스할 수 있는 웹 서버가 있다고 가정하겠습니다.
우리의 "가.법인.example.com" 예에서는 "go"가 내부자만 액세스할 수 있는 하위 도메인에 있고 ShortName 서비스를 사용하려면 VPN이 필요하다는 의미입니다. Google Apps는 일반적으로 VPN 없이 작동하도록 구성되므로(모든 액세스는 HTTPS), 이는 차선책입니다.
우리의 "가.내선.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.내선.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 검색 경로가 설정되어 있어야 합니다.
corp.example.comDHCP를 사용하는 클라이언트는 DHCP 서버에 도메인이 아직 포함되지 않은 경우 검색 경로 앞에 도메인을 추가하도록 구성해야 합니다 .
다음은 다양한 DHCP 서버 및 운영 체제에서 이 작업을 수행하는 방법에 대한 지침입니다.
DNS 검색 경로를 포함하도록 DHCP 서버 구성:
- Windows DHCP 지침
할 것
- 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)
);
(테스트되지 않은) 두 개의 항목 검색 목록을 생성해야 합니다.
- dnsmasq DHCP 지침
할 것
정적으로 구성된 머신 구성:
- 윈도우
할 것
- 리눅스/유닉스
/etc/resolv.conf(1) "domain corp.example.com"이 첫 번째 줄인지, (2) "search" 줄을 추가/편집하여 도메인을 포함하는지 corp.example.com, (3) "options 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; 그리고 회사의 홍보 부서와 다른 사람들에게 항상 그런 식으로 지정하도록 교육하는 데 시간을 투자하세요.
또는 적어도 링크 텍스트에 "go"가 표시되도록 HTML로 인코딩하지만 실제 HREF는 FQDN으로 이동합니다.
<a href="http://go.example.com/lunch">go/lunch</a>
홍보 부서 사람들에게 이를 가르치는 것은 어려울 수 있습니다. go.example.com짧은 "go/lunch"는 우연히 작동하기 때문에 작성하는 모든 항목에 긴 버전( )을 사용해야 한다고 말하고 싶을 수도 있습니다.
8단계: HTTPS
TODO: HTTPS를 사용하는 방법을 알아보세요(인증을 제대로 받는 것은 불가능하지는 않더라도 매우 어려울 것입니다).
답변1
이 질문은 어떤 식으로든 "답변"으로 표시되어야 합니다. 이런 식으로,https://serverfault.com/unansweredURL은 올바른 상태로 유지됩니다. 이 질문에 대한 "답변"을 (게시하고) 수락하십시오. 감사해요!
내 "대답"은 링크 단축 서비스를 구축(또는 설치)하는 것이 매우 쉽다는 것입니다. 위의 모든 과정을 거치는 대신 "go. example.com"을 입력하고 DNS가 example.com 검색에 응답하는지 확인하세요. 이렇게 하면 내부 URL이 외부로 유출되지 않습니다. (아마 제가 요점을 놓치고 있는 것 같습니다.)
대안:
아주 작은 회사나 작업 그룹의 경우 모든 사람에게 가장 좋아하는 책갈피를 물어보고 인트라넷 첫 페이지에 넣을 공간을 찾으세요.
또는 소규모 회사나 그룹을 위한 인트라넷을 위키로 배포하여 사람들이 가고 싶은 곳으로 쉽게 이동할 수 있도록 도와주는 공유 핫 링크 목록을 제공합니다.
건배, -대니