그 터널 주소는 피어이지, 탐색할 수 있는 서브넷이 아니다

클라이언트가 연결되면 주소 쌍을, 또는 주소 하나에 255.255.255.255 마스크가 붙은 모습을 보여 주고, 첫 반응은 서버가 뭔가 망가진 것을 줬다는 것이다. 아무것도 망가지지 않은 이유는 터널 인터페이스가 지점 간 링크이고, 마스크가 그 하나의 링크에서 먼 쪽 끝을 설명할 뿐 이웃 호스트의 범위를 뜻하지 않기 때문이다. 주소 쌍을 로컬 주소와 피어로 읽으면 이상한 마스크, 그 옆의 단일 호스트 경로, 빠져 있는 이웃 테이블이 설명된다. 같은 해석으로도 변명할 수 없는 것은 사무실 네트워크와 겹치는 주소 계획이다.

터널 링크에서 마스크가 잘못돼 보이는 이유

Ethernet 인터페이스에서 주소와 마스크는 이 호스트가 주소를 소유한다는 것, 그리고 프리픽스 안의 모든 것이 직접 이웃이라는 것, 두 가지를 말한다. 커널은 이 두 사실에서 링크상 경로를 도출하고, 존재한다고 여기는 이웃을 위해 링크 주소를 해석한다. 지점 간 인터페이스는 소유만 남기고 이웃을 버리므로, 클라이언트 줄의 두 번째 주소는 공유 세그먼트의 다른 호스트가 아니라 먼 쪽 끝이다. 하드웨어 주소 지정도, 해석 트래픽도, 가입할 브로드캐스트 도메인도 없기 때문에 이 인터페이스는 목적지가 정확히 하나인 관처럼 동작한다.

넓은 마스크 옆에 단일 호스트 경로가 있는 것이 여기서 증상이 아니라 정상인 이유도 같다. 이 링크에서 도달 가능성은 주소 하나를 뜻하고, 커널은 바로 그것을 기록한다. 두 주소를 함께 읽어라 구성이 잘못됐다고 판단하기 전에, 어느 하나만 보면 실수처럼 보이기 때문이다.

두 가지 토폴로지, 두 가지 주소 모양

오래된 지점 간 토폴로지는 각 클라이언트에 작은 블록을 주고 가운데 두 주소를 사용하므로, 마스크는 풀이 아니라 네트워크의 조각처럼 보인다. 서브넷 토폴로지는 풀에서 풀 마스크와 함께 주소를 주고 서버의 터널 주소를 피어라고 부른다. 둘 다 유효한 링크를 만들고, 프로필에 어떤 주소가 나타나는지와 사용자가 의문을 품을 만한 마스크에서만 다르다.

어느 줄이 클라이언트에 맞든 먼저 피어를 읽어라, 먼 쪽 끝을 지목하므로 마스크를 설명해 준다. 토폴로지가 다른 서버 사이에서 복사한 프로필은 새 집에 맞지 않는 모양을 보여 주고, 그 불일치는 서버 결함으로 오해되기 쉽다.

풀과 사무실 네트워크가 같은 비트를 요구할 때

링크가 라우팅되므로 풀에는 서버가 닿을 수 있는 네트워크 어디에도 없는 프리픽스가 필요하다. 하나를 공유하면 클라이언트는 두 장소를 뜻하는 범위에 경로 하나만 갖게 되고, 어느 장소가 이길지는 마지막에 설치된 경로가 정한다. 장애는 클라이언트에서 나타나지만 그 뒤의 결정은 주소 계획에 속한다. 사용자들이 보고하는 것은 터널이 올라오면 로컬 라우터가 사라진다거나 일부 사무실 호스트만 응답한다는 것이다.

비슷해 보일 뿐인 프리픽스는 다른 사례이고, 옥텟을 눈으로 비교하는 것은 프리픽스 비교가 아니다. 둘 다 적고 마스크된 비트를 세라: 192.168.4.0/24 대 192.168.6.0/24 비트 22까지 일치하고 비트 23에서 갈라진다, 세 번째 옥텟이 00000100 대 00000110 로 읽히기 때문이며, 따라서 그 두 네트워크는 정말로 별개다. 10.8.0.0/24 옆에 다른 10.8.0.0/24 를 두면 마스크된 24비트가 모두 일치하고, 이는 경로 하나로 두 장소를 표현할 수 없다는 뜻이다. 비교가 어디서 멈추는지는 마스크 길이가 정하고, 두 번째로 설치된 네트워크가 지는 쪽이다.

라우팅된 링크가 전달할 수 없는 것

브로드캐스트와 멀티캐스트는 라우팅된 링크를 넘지 않으며, 여러 익숙한 기능이 그것들 위에 세워져 있다. 탐색 목록, 이름 공지, 서비스 검색은 모두 공유 세그먼트를 전제하므로 파일 서버는 주소로 모든 요청에 답하면서도 목록에는 결코 나타나지 않을 수 있다. 링크 로컬 브로드캐스트에 의존하는 이름 해석도 같은 이유로 실패하고, 프로필을 어떻게 편집해도 터널이 실어 나를 수 있는 것은 바뀌지 않는다. 그것이 중요한지는 라우팅이 아니라 요구 사항의 문제다.

그 전달이 정말로 필요한 클라이언트에는 브리지 인터페이스가 필요하고, 그것은 Ethernet 프레임을 실어 나르므로 브로드캐스트 도메인을 유지한다. 대가는 더 시끄러운 링크, 위에서 설명한 깔끔한 주소 지정의 상실, 그리고 루프가 생긴 뒤의 훨씬 큰 장애 표면이다. 바꾸기 전에 요구 사항을 정당화하고, 요구 사항이 이름에 관한 것일 때는 라우팅된 링크에서 동작하는 이름 서비스를 선호하라.

프로필을 편집하기 전에 인터페이스 읽기

프로필이 말하는 것처럼 보이는 것이 아니라 커널이 무엇을 설치했는지 물어라. 주소 출력은 마스크를 설명하는 피어를 보여 주고, 경로 출력은 그곳으로 가는 길이 있는지 보여 준다. 둘 다 터널 장치에 대해 실행하면 잠깐이면 되고 질문은 정리된다.

ip -4 addr show dev tun0
ip route show dev tun0
ip route get 10.8.0.1

그 셋이 일치하면 프로필은 구성된 대로 동작하고 있고, 남은 문제는 다른 곳에 있다. 토폴로지는 빠진 능력을 지목하는 이유가 있을 때만 바꿔라, 낯선 마스크는 그런 이유가 아니기 때문이다.