172.31.0.0/16오늘 우연히 서브넷의 주소를 ping하고 ICMP 응답을 받을 수 있다는 사실을 발견했습니다 . 나는 무작위로 몇 가지를 시도했지만 항상 응답을 받았습니다. 라우팅 테이블과 임시 결과를 확인한 후에 traceroute관련 패킷이 내 로컬 네트워크를 떠나는 것, 즉 내 ISP를 향해 떠나는 것 같습니다. 내 로컬 네트워크는 서브넷의 일부인 다른 IP 범위를 사용하며 및 192.168.0.0/16에는 Docker 관련 인터페이스가 있지만 에는 없습니다 .172.17.0.0/16172.19.0.0/16172.31.0.0/16
172.31.0.0/16IANA에 예약된 주소 공간 의 일부가 여전히 남아 있어야 한다는 것이 제가 이해한 바입니다 172.16.0.0/12.
글로벌 IP 주소 부족이나 다른 이유로 인해 이 서브넷의 범위가 단축되었는지 확인하기 위해 웹 검색을 시도했지만 해당 가설을 뒷받침하는 항목을 찾을 수 없었습니다.
이제 저는 잠이 부족해서 기본적인 것을 간과하고 있는 것인지, 아니면 네트워킹 설정에 심각한 문제가 있는 것인지 궁금합니다.
답변1
172.31.0.0/16이 RFC1918 IP 주소 공간의 일부인 것이 맞습니다. 귀하의 라우터는 연결되지 않은 경로를 향한 트래픽을 기본 게이트웨이인 ISP로 덤프하도록 구성되어 있을 가능성이 높습니다. 그곳에서 교통이 멈춰야 합니다.
그러나 ISP가 이 주소 범위를 라우팅 가능하게 만든 것 같습니다. 과거에 다른 ISP에서 이런 일이 발생하는 것을 본 적이 있습니다(예를 들어 Tele2는 IANA에서 할당하기 전에 백본에 1.0.0.0/8을 사용했습니다).
어느 쪽이든 귀하(및 귀하의 ISP)는 아마도 구현해야 할 것입니다.보곤 필터링및/또는화성 필터링네트워크 경계에 있습니다. 일반 가정 소비자의 경우 이는 변명의 여지가 있지만 ISP가 더 잘 알아야 합니다.
이 문제를 방지하려면 라우터 방화벽에 기본 발신 필터를 설정할 수 있습니다(예: 10.0.0.0/8, 127.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, and 169.254.0.0/16). 또 다른 옵션은 null 라우팅 또는블랙홀 경로이 주소 범위. 그러면 라우터가 패킷을 삭제합니다.