경로 원본 인증은 디지털로 서명된 RPKI BGP에서 IP 프리픽스를 원천으로 할 수 있는 ASN을 식별하는 레코드입니다. 해당 인터넷 숫자 자원을 보유한 조직에 의해 생성되거나, 그 대신에 생성됩니다. ROA는 일반적으로 세 가지 필수 요소를 포함합니다: IP 프리픽스, 승인된 원천 ASN 및 해당 ASN이 공지할 수 있는 최대 프리픽스 길이입니다. 예를 들어, 한 조직은 IPv4 프리픽스 203.0.113.0/24을 관리하고 AS64500을 사용하여 이를 공지할 수 있습니다. 해당 ROA는 AS64500이 이 /24을 원천으로 할 수 있도록 승인할 수 있습니다. 간단히 말해, 이 레코드는 라우팅 생태계에게 다음과 같은 지시를 전달합니다: "이 ASN은 이 프리픽스를 공지할 수 있습니다." RPKI 검증을 수행하는 네트워크는 이후 BGP에서 관찰되는 내용과 이 레코드를 비교할 수 있습니다. ROA는 IP 주소 블록의 소유권을 이전하지 않습니다. 계약, 등록 기록, 할당 기록 또는 IPv4 이전 계약을 대체하지 않습니다. 단지 경로의 원천과 관련된 권한을 발표할 뿐입니다. 법적 통제와 라우팅 권한은 연결되어 있지만, 동일한 것이 아닙니다. ROA는 IPv4 및 IPv6 자원 모두에 대해 생성될 수 있습니다. 형식은 유사하지만, 프리픽스 길이와 운영 설계는 다를 수 있습니다. IPv4 네트워크는 일반적으로 /24와 같은 프리픽스를 사용하는 반면, IPv6 네트워크는 /32, /36, /48 또는 자신의 할당 및 라우팅 계획에 적절한 다른 길이의 집약체를 자주 공지합니다.
ROA가 필요한 이유는 무엇입니까?
ROA가 없으면, 다른 네트워크는 BGP 원본 ASN이 접두사를 발표하는 것을 허용한다고 확인하기 위해 RPKI 기반의 권한을 가지지 못합니다. 이 경로는 여전히 정당할 수 있지만, 일치하는 권한이 없기 때문에 RPKI 검증 중 일반적으로 '찾을 수 없음' 결과를 생성하게 됩니다. '찾을 수 없음' 결과는 자동으로 라우팅 문제는 아닙니다. 인터넷상 많은 유효한 경로는 ROA를 가지고 있지 않습니다. 그러나 조직이 정확한 ROA를 게시하면, 다른 네트워크에게 예상되는 원본을 비인가되거나 잘못 구성된 원본과 구분할 수 있는 더 강한 신호를 제공하게 됩니다. 접두사가 가치가 있거나, 비즈니스에 필수적이거나, 널리 발표될 때 ROA는 특히 유용합니다. 기업은 공공 서비스에 자체 주소 공간을 사용할 수 있고, 클라우드 플랫폼은 고객 인프라를 발표할 수 있으며, 호스팅 제공자는 여러 위치에서 대규모 주소 범위를 광고할 수 있습니다. 이러한 상황에서는 잘못된 원본이 많은 사용자와 서비스에 영향을 줄 수 있습니다. ROA는 사고 대응 중에도 도움이 됩니다. 만약 접두사가 예상되지 않은 ASN에서 갑자기 나타나면, 네트워크 운영자는 RPKI 상태를 확인하고 해당 발표가 자원 소유자가 게시한 의도와 충돌하는지 빠르게 판단할 수 있습니다. 이는 사고의 모든 세부 사항을 설명하지는 않지만, 조사에 중요한 시작점이 됩니다. 여러 상류 공급자를 사용하는 조직의 경우, 어떤 공급자가 경로를 운송하든 일관된 권한을 제공할 수 있습니다. 공급자는 변경될 수 있지만, 원본 ASN은 동일하게 유지될 수 있습니다. 이 경우, 전송 경로가 변경되었다고 해서 ROA를 변경할 필요는 일반적으로 없습니다.
ROA는 BGP와 어떻게 작동합니까?
BGP는 자율 시스템 간에 경로 공지사항을 배포합니다. 일반적으로 경로 공지사항에는 IP 접두사와 원본 ASN이 포함되며, 기타 경로 및 정책 정보도 포함됩니다. 원본 ASN은 해당 경로의 출처라고 주장하는 자율 시스템입니다. RPKI 검증은 BGP와 함께 작동합니다. 검증자는 RPKI 시스템에서 서명된 권한 데이터를 검색하고, 해당 기록이 진위 여부와 최신 상태를 확인합니다. 그런 다음 라우터, 경로 서버 또는 경로 정책 시스템에 사용할 수 있는 검증된 데이터 세트를 생성합니다. 네트워크가 BGP 공지사항을 받으면, 공지된 접두사와 원본 ASN을 검증된 ROA 정보와 비교합니다. 세 가지 주요 결과가 있습니다. 공지사항은 유효, 무효 또는 찾을 수 없음일 수 있습니다. 유효한 결과는 공지사항이 ROA에 의해 커버되고 원본 ASN이 허가되었음을 의미합니다. 무효 결과는 관련 ROA가 존재하지만, 공지사항이 그와 충돌한다는 것을 의미합니다. 찾을 수 없음 결과는 적용 가능한 ROA가 발견되지 않았음을 의미합니다. 수신 네트워크는 이러한 결과에 대해 어떤 조치를 취할지 결정합니다. 일부 운영자는 무효 경로를 거부합니다. 다른 운영자는 더 낮은 선호도를 할당하거나 알림을 생성하거나 소스에 따라 다른 정책을 적용할 수 있습니다. 모든 네트워크에 대한 단일한 보편적인 정책은 없지만, 많은 공급업체는 무효 공지사항을 중요한 경로 보안 문제로 간주합니다. 중요한 점은 ROA가 직접적으로 글로벌 인터넷을 통제하지 않는다는 것입니다. ROA는 권한 정보를 발표합니다. 실제 효과는 다른 네트워크가 이 정보를 검색하고 검증하여 경로 결정에 사용하는지 여부에 달려 있습니다.
ROA의 세 가지 주요 부분
ROA의 첫 번째 부분은 권한이 부여된 IP 접두사이며, 이는 원본 ASN이 발표할 수 있는 주소 범위를 식별합니다. IPv4의 경우 접두사는 198.51.100.0/24일 수 있으며, IPv6의 경우 2001:db8:1234::/48일 수 있습니다. 접두사는 해당 조직이 관련 레지스트리 또는 후원 관계를 통해 관리할 수 있는 자원과 일치해야 합니다. 오타, 잘못된 네트워크 경계 또는 잘못된 접두사 길이는 ROA가 효과적이지 않거나 의도한 범위와 다른 범위를 권한 부여할 수 있으므로 정확하게 입력해야 합니다.
두 번째 부분은 해당 접두사를 발신할 수 있는 권한이 있는 원본 ASN이며, BGP 공지에서 원본으로 나타나는 ASN과 일치해야 합니다. 회사가 주소 블록을 소유하지만 전송 제공업체의 ASN을 통해 이를 공지하는 경우, 올바른 원본은 실제 경로 설계에 따라 달라집니다. ROA에 있는 ASN은 일반적으로 경로를 발신하는 ASN이어야 하며, 단순히 상류 운송업체의 ASN일 필요는 없습니다. 이 구분은 중요합니다. 전송 제공업체는 경로를 운반할 수 있지만 원본이 아닐 수 있기 때문입니다. 고객의 ASN이 접두사를 발신하고 제공업체는 오직 운반만 수행하는 경우, 일반적으로 승인되어야 하는 값은 고객의 ASN입니다.
세 번째 부분은 최대 접두사 길이로, 일반적으로 maxLength라고 불리며 ROA에 의해 커버되는 동안 공지가 얼마나 특정할 수 있는지를 정의합니다. ROA가 198.51.100.0/24을 /24의 최대 길이로 승인한다고 가정해 보겠습니다. 승인된 ASN은 정확한 /24를 공지할 수 있지만, /25 또는 /26과 같은 더 작은 하위접두사를 공지하는 것은 승인되지 않습니다. 동일한 접두사가 /26의 최대 길이로 승인된다면, /24, /25 및 /26의 공지는 정확한 경로와 검증 규칙에 따라 커버될 수 있습니다. 이는 유연성을 제공하지만, 더 구체적인 공지도 허용합니다. 따라서 최대 길이는 실제 라우팅 계획을 반영해야 합니다. 너무 짧게 설정하면 합법적인 더 구체적인 경로가 무효가 될 수 있고, 너무 길게 설정하면 조직이 의도하지 않은 공지를 승인할 수 있습니다.
maxLength이 중요한 이유는 무엇인가요?
최대 접두사 길이는 ROA 설정 중 가장 중요하고 자주 오해되는 설정 중 하나이며, 승인된 ASN이 자원을 발표할 때 사용할 수 있는 세부 수준을 제어합니다. 많은 네트워크 운영자는 라우팅 테이블 성장 감소를 위해 집약적 접두사를 발표합니다. 예를 들어, 조직이 /20을 보유하고 있지만 단일 집약적 접두사로 발표할 수 있습니다. 일부 경우에 조직은 트래픽 공학, 지역 연결 또는 서비스 분리를 위해 더 작은 접두사를 발표해야 할 수도 있습니다. ROA가 집약적 접두사만을 커버하는 경우 네트워크가 더 세부적인 경로를 발표하면 해당 경로는 '무효'로 분류될 수 있습니다. BGP 발표는 조직의 관점에서 기술적으로 올바를 수 있지만, RPKI에 게시된 권한과 일치하지 않습니다. 반면에 모든 가능한 더 세부적인 경로를 승인하는 것은 정책의 정확도를 약화시킬 수 있습니다. 예를 들어, 매우 광범위한 최대 길이로 /20을 승인하면 의도된 설계 외에도 훨씬 작은 하위 접두사가 승인된 것으로 나타날 수 있습니다. 실용적인 접근법은 네트워크가 주소 계획, 공급업체 요구사항, 장애 대응 설계 및 트래픽 공학 전략에 따라 실제로 발표할 것으로 예상되는 접두사 길이만을 승인하는 것입니다. 최대 길이의 변경 사항은 엄격한 필터링을 적용하기 전에 모든 생산용 발표가 예상된 검증 결과를 반환하는지 확인하면서 신중하게 테스트해야 합니다.
ROAs for IPv4 and IPv6
IPv4 및 IPv6 네트워크 모두에 ROA를 생성할 수 있으며, 기반 보안 원리는 동일합니다. 즉, 접두사와 승인된 원본 ASN을 연결하는 것입니다. 주요 운영 차이점은 주소 구조입니다. IPv4 자원은 제한적이며 일반적으로 상대적으로 작은 접두사에서 발표되며, 공개 인터넷에서 /24는 일반적인 최소 발표 크기입니다. IPv6 네트워크는 일반적으로 더 큰 할당량을 받으며, 이를 사이트, 서비스 또는 지리적 세그먼트로 나누고 하나의 집약적 접두사를 발표하면서 여러 내부 접두사를 사용할 수 있습니다. ROA는 공개적으로 발표된 접두사와 일치해야 합니다. IPv6 운영자는 대규모 주소 공간이 라우팅 위험을 제거한다고 가정해서는 안 되며, 비승인된 IPv6 발표가 여전히 접근성 문제, 트래픽 전달 또는 일관되지 않은 글로벌 라우팅을 초래할 수 있기 때문입니다. RPKI는 IPv6 운영자에게 IPv4 운영자와 동일한 원본 권한 게시 기회를 제공합니다. IPv6 ROA를 생성하기 전에 네트워크 팀은 어떤 집약적 접두사를 발표할지, 더 특정한 발표가 예상되는지, 그리고 어떤 ASN이 원본이 될지를 문서화해야 하며, 너무 제한적이거나 불필요하게 광범위한 기록을 피해야 합니다.
ROA를 언제 생성해야 하나요?
생산 환경에서 접두사가 발표되기 전에, 자원 보유자가 명확한 경로 계획을 가지고 있는 경우 ROA(Route Origin Authorization)를 생성해야 합니다. 이는 검증 네트워크가 경로가 광범위하게 노출되기 전에 정보를 검색할 시간을 제공하기 위함입니다. 조직은 새로운 할당을 받을 때, IPv4 블록을 인수할 때, 주소 전송을 완료할 때, 원본 ASN(자원 개체 번호)을 변경할 때, 또는 새로운 IPv6 할당을 사용하기 시작할 때 ROA를 검토해야 합니다. 이러한 이벤트들은 접두사와 원본 네트워크 간의 관계를 변경하기 때문입니다. 공급업체 이전도 일반적인 트리거 중 하나입니다. 조직이 동일한 원본 ASN을 유지하고 단지 상류 공급업체만 변경하는 경우, ROA는 여전히 유효할 수 있습니다. 그러나 이전이 원본 ASN을 변경하는 경우, 경로 변경 전이나 동시에 ROA를 업데이트해야 합니다. 합병, 인수, 데이터 센터 이전, ASN 후원 변경 및 대규모 네트워크 재설계 시 ROA를 검토하여 공개 승인이 운영 현실과 일치하도록 해야 합니다. 알려진 변경 사항이 없어도 주기적으로 ROA를 검토하는 것이 유용합니다. 네트워크 문서가 오래되어 가고, 직원 책임이 변경되며, 원래 경로 설계가 대체된 후에도 오래된 승인이 활성 상태로 남아 있을 수 있기 때문입니다.
흔한 ROA 구성 오류
가장 흔한 오류 중 하나는 잘못된 원본 ASN을 입력하는 것이며, 이는 엔지니어들이 고객 ASN과 운송 공급업체 ASN을 혼동하거나 마이그레이션 후 구 ASN이 구성에 남아 있는 경우 발생합니다. 또 다른 흔한 실수는 IPv4 전달 후 ROA를 업데이트하지 않는 것입니다. 새 소유자가 자신의 ASN에서 접두사를 발표할 때 기존 권한은 이전 원본을 가리키고 있어 경로가 무효가 되기 때문입니다. 잘못된 최대 길이는 조직이 /24만 승인했지만 이후 트래픽 엔지니어링을 위해 /25를 발표할 때 유사한 문제가 발생합니다. 일부 조직은 목적을 문서화하지 않고 여러 겹치는 ROA를 생성합니다. 특정 설계에서는 유효하지만 예상치 못한 결과를 초래하고 문제 해결을 복잡하게 만들 수 있습니다. 오래된 레코드를 제거하지 않으면 네트워크 설계가 변경된 후에도 ASN이 접두사를 원본으로 발표할 수 있습니다. 마지막으로, 일부 조직은 자체 발표를 먼저 테스트하지 않고 무효 경로를 엄격히 거부하도록 설정합니다. 생산용 접두사, 최대 길이 및 원본 ASN은 자동 필터링에 의존하기 전에 항상 검증되어야 합니다.
ROA and IPv4 Transfer Planning
IPv4 전송은 관리 보유자, 후원 arrangement 및 라우팅 원본이 프로세스의 다양한 단계에서 변경될 수 있기 때문에 특별한 주의가 필요합니다. 전송 전에 현재 보유자는 기존의 ROA를 문서화하고 현재 해당 접두사의 원본 ASN을 확인해야 하며, 구매자는 의도된 원본 정보를 준비하고 트랜지트 공급업체와 협조해야 합니다. 전환 중에는 양 당사자가 인가 기록을 업데이트하거나 교체하기 위한 명확한 계획이 필요합니다. 이전 ROA를 너무 오래 활성 상태로 두면 전송 후에도 이전 원본이 승인되는 반면, 너무 일찍 제거하면 새 경로가 준비되기 전에 기존 경로가 무효가 됩니다. 정확한 절차는 레지스트리, 자원 유형, 전송 계약 및 운영 설계에 따라 달라지며, RPKI는 레지스트리 검증, 계약 검토, BGP 발표, 경로 개체, 역방향 DNS 및 명성 스크리닝과 함께 필수 체크리스트 항목입니다. 공개 준비 체커는 접두사의 현재 원본 ASN, RPKI 상태, 레지스트리 정보 및 BGP 가시성을 기술적 사전 검사에 사용할 수 있지만, 법적 소유권을 확인하거나 전송 자격을 보장하지 않습니다.
ROA 및 ASN 변경 사항
ASN 변경은 RPKI 검증에 직접적인 영향을 미칩니다. 이전에 AS64500이 발표한 접두사가 이제 AS64510에서 발표된다면, BGP 발표가 유효하게 인정되기 전에 ROA가 새로운 원본을 승인해야 합니다. 이는 조직이 공급자 관리 ASN에서 자체 ASN으로 이동하거나, 지원하는 LIR 협정을 변경할 때 특히 중요합니다. 이 경우 등록소 관계와 경로 승인 권한을 함께 검토해야 합니다. 철저히 계획된 전환은 오래된 및 새 원본 모두를 일시적으로 승인하여 통제된 마이그레이션 기간을 생성할 수 있으며, 이는 문서화되어 있고 완료 후 사용되지 않은 승인이 제거될 경우에만 가능합니다. 네트워크 팀은 생산 변경을 수행하기 전에 운영 순서를 테스트해야 하며, 새 승인이 게시되고 검증된 후에 새 BGP 경로를 발표해야 합니다.
ROA가 작동하는지 확인하는 방법은 무엇입니까?
첫 번째 검사는 관련 RIR 포털, 후원 LIR 인터페이스 또는 RPKI 관리 시스템을 통해 ROA에 의도한 접두사, 원본 ASN 및 최대 접두사 길이가 포함되어 있는지 확인하는 것입니다. 다음으로, 인증을 실제 BGP 발표와 비교하여 발표된 접두사 길이가 커버되었는지 그리고 원본 ASN이 ROA와 일치하는지 확인합니다. 외부 RPKI 검증 도구를 사용하면 공개 상태를 확인할 수 있으며, 올바르게 구성된 발표는 "유효"를 반환합니다. 결과가 "무효"인 경우 먼저 원본 ASN과 접두사 길이를 점검해야 합니다. "찾을 수 없음"인 경우, ROA가 게시되었는지 확인하고 검증 도구가 이를 검색할 시간이 있었는지 확인해야 합니다. 결과는 저장소, 검증 도구 및 라우팅 시스템이 갱신 간격에 의존하기 때문에 즉시 업데이트되지 않으며, 전파 중에는 짧은 지연이 일반적입니다. 등록 데이터, 검증 결과 및 현재 BGP 관측을 포함한 여러 공개 소스를 비교함으로써 캐시된 정보에만 의존하지 않고 전체적인 그림을 제공할 수 있습니다.
ROA가 유효하지 않을 때 발생하는 일은 무엇입니까?
BGP 발표가 기존 ROA와 충돌할 경우, RPKI 검증기는 이를 '무효'로 분류합니다. 이 경로는 글로벌 인터넷에서 자동으로 제거되지 않지만, RPKI 기반 정책을 시행하는 네트워크는 이를 거부하거나 낮은 선호도를 부여할 수 있습니다. 운영적 영향은 정책 시행 범위에 따라 달라집니다. 일부 네트워크는 엄격하게 필터링하는 반면, 다른 네트워크는 상태를 모니터링용으로 사용하기 때문에 '무효' 경로는 인터넷 일부 영역에서는 보이지만 다른 영역에서는 접근 불가능해질 수 있습니다. 합법적인 경로가 '무효'가 되었을 경우, 해당 조직은 이를 긴급한 구성 문제로 간주해야 하며, 원본 ASN, 공지된 접두사 길이 및 ROA 최대 길이의 검토를 우선시해야 합니다. 경로가 악의적인 것으로 간주되어서는 안 되며, 대부분의 '무효' 결과는 완전하지 않은 이전 이전, 오래된 레코드, 잘못된 제공업체 세부사항 또는 실수로 더 구체적인 발표와 같은 일반적인 실수에서 비롯됩니다. 수정 후 시스템은 갱신 시간이 필요하며, 네트워크 팀은 모든 관찰 포인트에서 경로가 안정화될 때까지 경로를 모니터링해야 합니다.
ROA를 어떻게 관리해야 하나요?
ROA 관리는 네트워크 엔지니어링 팀, 보안 팀, 후원 LIR, 관리 서비스 공급업체 또는 인터넷 번호 자원을 담당하는 기타 그룹 중 어느 것이든 명확한 소유자가 필요합니다. 조직은 변경 검토 및 사고 대응을 간단하게 하기 위해 각 프리픽스, 원본 ASN, 최대 길이, 발표 위치 및 책임 연락처를 상세히 기재한 재산 목록을 유지해야 합니다. ROA 변경 사항은 표준 네트워크 변경 절차에 통합되어야 하며, ASN 이전, 제공업체 전환, IPv4 이전 또는 IPv6 배포 시 RPKI를 명시적인 요구사항으로 처리해야 합니다. 잘못된 결과, 예기치 못한 원본, 제거된 권한 또는 BGP 가시성의 변화에 대해 모니터링 및 경고가 구성되어야 합니다. 중요한 것은 조직이 너무 광범위한 권한을 부여하지 않는 것입니다. 정확한 ROA는 이해하기 쉬우며 감사가 더 간단하고 의도하지 않은 발표를 허용할 가능성이 훨씬 적습니다.
자주 묻는 질문
ROA는 IP 소유권 문서와 동일한가요?
아니요. ROA는 BGP에서 접두사를 생성할 수 있는 ASN을 나타내는 경로 승인입니다. 등록 기록, 계약, 이전 문서 또는 법적 소유 증거를 대체하지 않습니다.
한 번의 프리픽스에 여러 개의 ROA가 있을 수 있습니까?
네. 한 접두사가 여러 ASN에 의해 의도적으로 생성될 때 또는 통제된 이전이 다중 원본에 대한 임시 승인을 필요로 할 때 여러 ROA가 적절할 수 있습니다. 그러나 겹치는 레코드는 철저히 문서화되어야 합니다.
ROA는 내 프리픽스를 BGP에 공지합니까?
아니요. ROA를 생성한다고 해서 BGP 공지가 생성되는 것은 아닙니다. 네트워크는 여전히 라우터와 상류 공급업체를 통해 BGP를 구성해야 합니다.
전송 공급업체는 ROA에 등록되어야 하나요?
일반적으로 ROA는 경로를 생성하는 ASN을 식별해야 합니다. 경로만 운송하는 공급자는 반드시 원본 ASN은 아니며, 올바른 값은 실제 라우팅 아키텍처에 따라 달라집니다.
ROA는 얼마나 오래 걸려서 보이는가?
시간은 RIR 시스템, 공개 저장소, 검증기 갱신 간격 및 캐싱에 따라 달라집니다. 업데이트는 일반적으로 상대적으로 빠르게 표시되지만, 운영 변경 사항에는 검증을 위한 충분한 시간이 있어야 합니다.
모든 IPv4 및 IPv6 접두사에 ROA가 있어야 하나요?
BGP에서 발표된 접두사에 대한 정확한 ROA 게시는 매우 권장됩니다. 조직은 먼저 자신의 라우팅 설계를 확인하여, 인가가 합법적인 발표를 실수로 무효로 하지 않도록 해야 합니다.
ROA는 모든 BGP 공격을 방지할 수 있나요?
아니요. ROA(경로 검증 개체)는 주로 원본 검증을 지원합니다. BGP 경로의 모든 부분을 검증하거나 모든 경로 누출을 방지하거나 트래픽을 암호화하거나 트래픽이 안전한 물리적 경로를 따르도록 보장하지 않습니다.
경로 원본 승인(Route Origin Authorization)은 RPKI의 핵심 구성 요소로, BGP에서 해당 프리픽스를 원본으로 발표할 수 있는 AS 번호와 IP 프리픽스 사이의 암호화된 서명된 관계를 설정합니다. 이 레코드에는 일반적으로 프리픽스, 원본 AS 번호 및 최대 프리픽스 길이가 포함되며, 각각은 자원을 식별하고 원본을 허용하며 발표가 얼마나 구체적인지를 정의하는 결정적인 역할을 합니다. 정확한 ROA는 네트워크가 비승인 또는 잘못 구성된 발표를 식별하는 데 도움이 되며, IPv4 전송, AS 번호 변경, 공급업체 이전, IPv6 배포 및 다중 호밍 네트워크 운영 중에 필수적입니다. 동시에 ROA는 법적 소유권의 증거이거나 독자적인 경로 보안 솔루션이 아니며, 정확한 등록 기록, 엄격한 BGP 구성, IRR 데이터, 경로 모니터링 및 문서화된 변경 프로세스와 함께 작동할 때 가장 효과적입니다. 공개 IPv4 또는 IPv6 공간을 발표하는 모든 조직에게 실용적인 규칙은 간단합니다. 사용하려는 원본만 발표하고, 실제로 발표하려는 프리픽스 길이만 승인하며, 네트워크가 변경될 때마다 레코드를 검토해야 합니다. 이는 RPKI 데이터를 실제 경로 환경과 일치시키고, 정당한 경로가 무효로 분류될 가능성을 줄이는 데 도움이 됩니다.