route -interface가 링크 밖 호스트에 도달하지 못하는 이유

route는 Wi-Fi 인터페이스 이름을 받아들이고 불평 없이 종료되며, 호스트는 여전히 도달할 수 없습니다. 훼손된 것은 없고, 라우트의 관계가 그저 잘못되었을 뿐이며, 인터페이스 플래그는 목적지가 어느 링크에 있는지 말할 뿐, 다른 곳에 있는 목적지의 트래픽을 어느 라우터가 받아야 하는지는 말하지 않습니다. 명령이 성공하는 것은 문법적으로 유효하기 때문이며, 동작하는 경로를 설명하기 때문이 아닙니다.

이 구분이 VPN 옆의 라우트 예외가 실제로 동작할지, 그저 그럴듯해 보일지를 결정합니다.

인터페이스는 출구이고, 다음 홉은 인계입니다

주소가 192.168.50.20인 Mac과 192.168.50.1의 라우터가 있을 때, 같은 링크의 다른 머신에는 직접 도달할 수 있습니다. 프레임은 그 머신을 향해 지정되어 케이블 위에 놓입니다. 라우터는 관여하지 않으며, 인터페이스로 한정된 라우트는 바로 그것을 표현합니다. 원격 쪽을 다른 건물의 호스트로 바꾸면 같은 명령은 의미가 없어집니다. Mac에는 케이블 위에 놓을 이 계층 주소가 없으므로 인터페이스 플래그가 설명할 것이 없습니다.

링크 밖의 목적지는 다릅니다. Mac은 이 계층에서 도달하지 못하는 호스트를 향한 프레임을 케이블 위에 놓을 수 없고, 도달할 수 있는 라우터에 패킷을 인계합니다. 따라서 라우트에는 게이트웨이가 필요하고, 게이트웨이 자체가 연결된 링크에서 도달 가능해야 합니다.

링크 밖 목적지에 인터페이스 플래그를 쓰면 macOS는 그 목적지를 케이블 위에 있는 것처럼 취급합니다. 그러면 커널은 그에 대한 이 계층 주소를 해석하지 못하고, 패킷은 오류에 유용한 정보 없이 버려집니다.

인터페이스 플래그가 실제로 주장하는 것

Apple의 라우트 참조는 중개자 없이 직접 도달 가능한 목적지에 대한 인터페이스 형식을 정의합니다. 이것은 링크 모델에 대한 진술이며, 어떤 어댑터를 쓸지에 대한 선호가 아닙니다. Wi-Fi로 인터넷 호스트에 도달하려면 여전히 그 Wi-Fi 링크의 라우터가 필요하고, 라우트는 그것을 지명해야 합니다.

인터페이스 스코프는 별개의 속성입니다. 어떤 소스 주소가 적용되는지 같은 스코프 결정을 위해 라우트를 특정 인터페이스와 연결하지만, 인터페이스 자체가 도달할 수 없는 목적지에 대한 도달성을 만들어 내지는 않습니다. 두 속성은 서로 다른 질문에 답합니다.

그래서 명령이 받아들여지고 테이블에 나타나도 실패할 수 있습니다. 커널은 의도를 검증하지 않고, 당신이 주장한 것을 기록할 뿐이며, 그 주장은 목적지가 링크 위에 있다는 것이었습니다. 조용한 성공 뒤의 조용한 폐기는 예상된 결과이며 버그가 아닙니다. 네트워크를 탓하기 전에 그 주장을 다시 읽어 보십시오.

링크 밖 목적지에 필요한 라우트

198.51.100.25 같은 문서용 주소로 가는 승인된 경로를 LAN 라우터를 통해 만들 때, 의도된 관계는 목적지, 192.168.50.1의 다음 홉, 그리고 그 다음 홉에 도달하는 LAN 인터페이스입니다. 인터페이스는 라우트 명령으로 강제되는 것이 아니라 다음 홉 조회에 의해 암시됩니다.

macOS에서 읽기 전용 확인은 route -n get 198.51.100.25입니다. 게이트웨이와 인터페이스 줄을 함께 읽고 게이트웨이가 Mac이 실제로 도달할 수 있는 주소인지 확인하십시오. 다른 서브넷의 게이트웨이나 마지막 네트워크 변경 이후 사라진 게이트웨이는 올바르게 보이지만 아무것도 전달하지 않는 라우트를 만듭니다.

지속되는 지침에 en0를 하드코딩하지 마십시오. 인터페이스 이름은 어댑터, 도크, VPN 클라이언트에 따라 바뀌며, 잘못된 이름을 쓰는 라우트는 더 넓은 네트워크 장애로 오해하기 쉬운 방식으로 실패합니다.

교체하기 전에 현재 선택을 읽으십시오

무엇이든 추가하기 전에 시스템이 이미 무엇을 선택했고 왜 그런지 확인하십시오. 그 출력은 트래픽이 터널로, LAN 라우터로, 아니면 어디로도 가지 않는지 알려 주고, 변경 후 비교할 기준선을 제공합니다. 그것이 없으면 새 라우트가 효력을 발휘했는지 알 수 없습니다.

그다음 주소 패밀리를 확인하십시오. IPv4용으로 추가한 라우트는 IPv6 목적지에 아무 효과가 없으며, 두 패밀리 모두로 해석되는 서비스는 간헐적으로 도달 가능해 보일 수 있습니다. 라우트 테이블과 리졸버는 서로 다른 질문에 답하며, 둘 다 의도한 경로와 일치해야 합니다.

마지막으로 라우트는 선택이지 허가가 아님을 기억하십시오. 관리형 VPN 프로필이나 클라이언트 필터는 테이블이 가리키더라도 직접 경로를 여전히 금지할 수 있으므로, 테이블 항목이 성공했다고 조사가 끝난다고 가정하지 말고 실제 애플리케이션으로 테스트하십시오.

터널과 정책이 형태를 바꿉니다

지점 간 인터페이스는 별개의 사례입니다. 터널은 이더넷 스타일의 게이트웨이 주소 없이 라우트를 나를 수 있으며, 그것이 자동으로 틀린 것은 아닙니다. 보이는 모든 테이블 항목에 Wi-Fi 예제를 확장하지 말고 인터페이스의 실제 링크 모델을 적용하십시오.

변경 요청에는 목적지, 승인된 네트워크 경로, 현재 게이트웨이와 인터페이스, 그리고 예외를 유지할 책임자를 적으십시오. 소유자가 중요한 이유는 프롬프트에 입력한 일회성 라우트는 정책이 아니며, 다음 재연결에서 지워지기 때문입니다.

VPN이 켜진 동안 이 호스트에 도달하는 것이 요구 사항이라면, 정직한 답은 보통 로컬 라우터를 통한 특정 호스트 라우트이며, 인터페이스를 소유한 네트워크 관리자가 설치합니다. 무엇이든 직접 도달하는 것이 요구 사항이라면, 그 요구 사항 자체가 라우트 명령보다 먼저 정책 검토를 필요로 합니다.