나는 두 개의 Raspberry Pi를 가지고 있습니다. 하나는 미디어 플레이어로 사용되고 다른 하나는 홈 서버로 사용됩니다(저는 이것을 플러그라고 부릅니다).
플러그인 중에서 SickBeard(TV 라이브러리), CouchPotato(영화 라이브러리), Sabnzbd(Usenet 다운로더) 및 Transmission(토렌트 다운로더)과 같은 웹 인터페이스가 있는 여러 애플리케이션을 설치했습니다. 이전에는 NGINX를 프록시로 사용했습니다. 따라서 내 기본 아이디어는 내 "플러그인의 IP"를 가리키는 모든 도메인이 사용된 도메인 이름을 기반으로 해당 애플리케이션의 웹 인터페이스에 대한 호출을 라우팅(프록시)하는 NGINX로 라우팅된다는 것입니다. 예를 들어, dl.plug.example.com(도메인 이름을 공개하고 싶지 않음)을 입력하면 Transmission 웹 인터페이스로 이동하고 usenet.plug.example.com을 입력하면 Sabnzbdplus 웹 인터페이스 pi.plug로 이동합니다. example.com은 내 다른 PI의 "원격" 인터페이스(미디어 플레이어로 사용됨)를 가리킬 것입니다. modem.plug.example.com은 내 라우터의 관리 페이지를 가리킵니다. 예상대로 작동합니다.
이제 BIND를 설치하고 구성했으므로 모든 요청이 플러그의 BIND 설치를 통과하도록 플러그의 IP를 DNS 서버로 사용하도록 모뎀을 설정했습니다. 내 목표는 다음과 같습니다
- 내 홈 네트워크에 연결된 모든 장치에서 .plug.example.com은 로컬 IP를 통해 애플리케이션을 호스팅하는 적절한 시스템으로 나를 연결해야 합니다. 즉, 집에 있을 때 휴대폰 브라우저에 dl.plug.example.com을 입력하면 192.168.1.x로 라우팅되어야 합니다. 외부에서 접근할 경우, 내 공용 IP로 라우팅되어야 합니다.
- 내 네트워크 내에서 호스팅되지 않는 다른 도메인 이름에 대한 요청의 경우 BIND가 Google DNS(8.8.8.8)를 통해 이를 해결하도록 합니다.
공용 IP 부분이 유효합니다. 즉, 네트워크 외부에서 액세스할 때 작동한다는 의미입니다. 내부 네트워크에서 시도하면 변동이 심합니다. 즉, 때로는 내 내부 IP를 통해 라우팅되지만 다른 경우에는 전체 네트워크(공용 IP를 통해 라우팅)를 통과하게 됩니다. 이것은 제가 고심하고 있는 문제입니다.
또 다른 문제는 때때로plug.example.com이 전혀 해결되지 않는다는 것입니다. BIND를 통해 시작하고 실행할 수 있습니다. 도메인 이름을 통해 터미널에서 SSH를 실행하면 가끔 해결되지 않는 경우가 있지만 IP를 사용하면 원활하게 실행됩니다. 그래서 내 BIND 구성에 문제가 있는 것 같아요. 내 모뎀 구성에 따라 모든 DNS 트래픽은 BIND 플러그인을 통과합니다. 그러니 이런 일은 일어나서는 안 됩니다.
BIND 구성을 다음에 업로드했습니다. https://drive.google.com/file/d/0B8TuY1aaTEhmbXRGVUkwbUh1bVU/view?usp=sharing
답변1
뇌관
이것은 실행 중인 젠투 설치의 호스트 파일입니다. 의견을 위해 실제 라우팅 지침을 제거했습니다. 라우팅에 대한 추가 정보:
# /etc/hosts: Local Host Database
#
# This file describes a number of aliases-to-address mappings for the for
# local hosts that share this file.
#
# In the presence of the domain name service or NIS, this file may not be
# consulted at all; see /etc/host.conf for the resolution order.
#
# Imaginary network.
#10.0.0.2 myname
#10.0.0.3 myfriend
#
# According to RFC 1918, you can use the following IP networks for private
# nets which will never be connected to the Internet:
#
# 10.0.0.0 - 10.255.255.255
# 172.16.0.0 - 172.31.255.255
# 192.168.0.0 - 192.168.255.255
#
# In case you want to be able to connect directly to the Internet (i.e. not
# behind a NAT, ADSL router, etc...), you need real official assigned
# numbers. Do not try to invent your own network numbers but instead get one
# from your network provider (if any) or from your regional registry (ARIN,
# APNIC, LACNIC, RIPE NCC, or AfriNIC.)
질문
개인 네트워크에 대한 마지막 설명 블록을 참고하세요. 개인 네트워크에 대한 네트워크 서비스를 구성할 때 대부분의 사람들이 잊어버리는 것은 내부 네트워크를 구분하는 가상의 선(네트워크로 구성된 네트워크)이 있다는 것입니다.RFC 1918, 그리고RFC 6761) 및 외부 네트워크(모든 실제 목적을 위한 인터넷), 여기서 도메인 IP 주소는 주로 다음으로 표시됩니다.IANA라고도 알려진 인터넷 할당 번호 관리 기관. IANA가 다음 사항을 담당하기 때문에 이는 허용되는 관행이기도 합니다.DNS 루트 영역, IANA DNS 서버는 도메인이 확인되는 위치에 대한 최종 결정권을 갖습니다. DNS 서버를 트리의 최상위 분기로 생각하십시오. 서버가 호스트를 확인할 수 없는 경우 요청은 트리 아래의 후속 분기로 전송됩니다. 각 분기의 크기가 커집니다. 트리 하단에는 IANA DNS 서버가 있습니다.
해결책
개인 네트워크 내의 라우팅은 개인 네트워크의 유지 관리/작성자가 처리합니다. Linux에서는 일반적으로 /etc/hosts BIND를 설치하고 구성하여 OP가 문제의 절반만 해결했습니다. BIND는 이름을 호스트 및 호스트:포트로 올바르게 라우팅하며 그 반대의 경우도 마찬가지입니다. 대부분의 서버에서 많이 사용되는 것 중 하나는제본외부 DNS 영역(개인 네트워크 외부 영역)을 내부 DNS 영역으로. 바라보다Linux DNS 서버 BIND 구성이에 대해 자세히 알아보세요. 또한 필요할 때 아래 섹션에서 해당 링크를 다시 참조하겠습니다.
내부 라우팅은 다양한 규칙(RFC 1918/6761)에 의해 관리되므로 정적 경로를 설정해야 합니다.주소와 이름 매핑은 BIND에서 작동합니다.. 이것이 구성되지 않은 경우 etc/hosts바인딩 맵은 요청을 라우팅할 위치가 아니라 내부적으로 라우팅하는 방법만 알고 있습니다. 이 문제를 해결하려면 로컬 매핑을 추가해야 합니다(OP가외부 BIND 설정올바르게 매핑됨):
# IPv4 and IPv6 localhost aliases
127.0.0.1 bedroom-gentoo.myISP.net bedroom-gentoo localhost
::1 bedroom-gentoo.myISP.net bedroom-gentoo localhost
그런 다음 로컬 솔루션(OP의 경우)
192.168.1.x sickbeard.plug.example.com sickbeard.plug sickbeard
192.168.1.x dl.plug.example.com dl.plug download
# Add others as needed.
위의 개인 네트워크 구문 분석은 다음과 같이 구문 분석될 수 있습니다.정규화된 도메인 이름, 호스트 이름만 추가됩니다. OP 및 다른 사람들은 원하는 동작에 따라 적절하게 조정할 수 있습니다. 생성된 모든 호스트 이름을 기억하는 것보다 개인 네트워크 내에서 FQDN을 사용하는 것이 더 쉽다는 것을 알았습니다.
2단계 - 선택사항이지만 선호됨
독자들이 네트워크 설정과 관련된 대부분의 답변에서 이 네트워킹 용어를 볼 수 있기 때문에 아래 링크를 추가했습니다. 이곳에 처음 오셨다면 꼭 읽어보세요. 오랫동안 사용했다면 건너뛰는 것이 좋습니다.
읽든 안 읽든 DHCP가 그 역할을 매우 잘 수행한다는 것을 알게 될 것입니다. 현재와 영원히 주요 기능은 공개 또는 비공개 주소를 제공하는 것입니다. DHCP가 잘 못하는 점은 DHCP가 제공하는 주소가 실제로 모든 유형의 서버에 속할 수 있다는 점을 기억하는 것입니다. 이는 OP와 다른 많은 독자들의 경우입니다. 이 상황은 장치 192.168.1.x의 IP 주소를 "소프트웨어로 예약"했기 때문에 여기에 적용됩니다 plug. 재부팅/재부팅 또는 정전 후 DHCP가 서버 주소를 어리석게 덮어쓰지 않도록 하려면 라우터에서 MAC 주소 바인딩을 사용해야 합니다. 다음 스크린샷은 Motorola Surfboard에서 촬영했지만 대부분의 주요 라우터 브랜드(D-LINK, NetGear, LinkSys/Cisco)에서 동일한 유형의 입력 화면을 본 적이 있습니다. 또한 어떤 사람은 Reserve로 이름을 붙이고, 어떤 사람은 Binding으로, 어떤 사람은 MAC Binding으로 이름을 붙일 수 있습니다.
OP의 경우 서버의 MAC 주소는 plug첫 번째 상자에 들어가고 파일의 마지막 옥텟 x는 /etc/hostsIP 주소 상자에 들어갑니다. 호스트 이름은 자동으로 입력되지만 etc/hosts필요한 경우 이름을 사용할 수 있습니다. 이렇게 하면 DHCP가 고정 IP 주소를 전달하도록 강제하기 때문에 호스트 파일을 수정할 필요가 없습니다. 반면에 스트리밍 서비스의 캐시가 약간 증가할 수 있습니다. 이전에 Roku 장치에서도 이와 동일한 개념을 사용한 적이 있습니다.