서버 주소 하나로 사무실 프리픽스를 추측하지 마세요

받은 주소에서 시작하되, 그것을 깔끔해 보이는 무언가로 넓히려는 충동을 참으세요. 10.22.8.19 의 서버 하나로는 사무실이 10.22.8.0/24 를 소유하는지, 10.22.0.0/16 인지, 흩어진 몇 개의 /28s 인지 알 수 없습니다. 숫자가 10 으로 시작한다고 10.0.0.0/8 을 고르면 의도하지 않은 가정용 네트워크, 컨테이너 범위, 파트너 링크까지 끌어옵니다. 프리픽스는 얻어야 하는 경계이지 추론할 대상이 아닙니다.

프리픽스 길이는 앞쪽 비트 몇 개가 유효한지를 설명할 뿐, 그 범위를 누가 소유하는지는 설명하지 않습니다.

서버 주소는 네트워크가 아닙니다

서버, 서브넷, 사이트는 서로 다른 세 가지입니다. 하나의 서비스가 작은 전용 서브넷에 있고 사무실의 나머지는 별도 범위를 차지할 수 있으며, 의도적으로 주소가 하나뿐인 서비스에는 호스트 경로가 완전히 적절할 수 있습니다. 사이트가 다른 호스트로 리디렉션하거나, 별도 서버로 인증하거나, 주소가 바뀌면 더는 적절하지 않습니다. 그런 의존성이 실제 요구사항이며, 어떤 프리픽스든 설치하기 전에 그것들을 물어볼 가치가 있습니다.

서브넷 계산기는 알려진 프리픽스를 마스크, 범위, 호스트 목록으로 바꿉니다. 호스트 이름 하나로 조직의 경계를 추론할 수 없으며, 그 출력을 권위로 취급하는 것이 관계없는 네트워크까지 라우팅되는 이유입니다.

승인된 프리픽스를 요청하세요

대상 범위는 VPN 이나 네트워크를 운영하는 사람에게서 받으세요. 서로 다른 여러 프리픽스와 별도 위치의 사설 DNS 서버가 있을 수 있고, 이는 이름이 실패할 때까지 자주 잊힙니다. 예제에서 재구성한 범위가 아니라 소유자와 날짜가 붙은 승인 목록으로 기록하세요. 목록이 길다면 그것은 네트워크에 관한 정보이며, 더 넓은 무언가로 요약하라는 초대가 아닙니다.

Mac 에서의 읽기 전용 경로 조회는 관심 있는 목적지를 향해 지금 어떤 경로가 쓰이는지 보여줍니다. 그것은 현재 동작이지 권한이 아닙니다.

무엇이든 적용하기 전에 겹침을 확인하세요

프리픽스를 적용하기 전에 가정용 LAN, 컨테이너 브리지, 가상 머신 네트워크, 다른 모든 VPN 을 포함한 모든 로컬 범위와 비교하세요. 같은 범위가 로컬에도 있으면 사무실로 가는 정확한 경로가 있어도, 표에는 그런 개념이 없기 때문에 그 주소의 어떤 기기를 뜻했는지는 알 수 없습니다. 겹침은 라우팅 실수보다 고장 난 서비스처럼 보이는 증상을 만들고, 나중에 진단하기 어렵습니다.

지원 담당 소유자가 클라이언트 자체 구성이나 서버가 밀어주는 경로를 통해 프리픽스를 설치하게 하여, 다시 연결할 때 복원되고 누군가 한 번 입력한 명령에 의존하지 않도록 하세요.

경로는 접근이 아닙니다

프리픽스를 터널로 라우팅한다고 그 안의 서비스에 접근할 수 있는 것은 아닙니다. 게이트웨이가 트래픽을 허용해야 하고, 목적지가 이를 받아들여야 하며, 돌아오는 경로가 있어야 하고, 각각은 경로와 무관하게 실패할 수 있습니다. 경로를 넣은 뒤 의도한 서비스 하나를 시험하고, 그다음 관계없는 리소스가 여전히 거부되는지 확인하세요. 방화벽에 도달하는 경로는 작동하는 연결과 같지 않습니다.

프리픽스 목록, 겹침 확인, 소유자를 함께 문서화하세요. 주소가 바뀌면 다음 사람에게 필요한 것은 그 세 가지입니다.

프리픽스는 경계에 관한 합의입니다. 그렇게 다루면 경로는 더 이상 추측이 아닙니다.