호스트 비트 때문에 경로가 거부되었나요? 의도한 프리픽스를 찾으세요

경로 줄이 거부되어 돌아오고, 찾은 조언은 IP 전달을 켜라고 말합니다. 이 두 가지는 문제의 다른 단계에 있습니다. 전달은 호스트가 인터페이스 사이에서 패킷을 옮길 수 있는지 결정할 뿐, 입력한 목적지가 유효한 네트워크인지에 대해서는 의견이 없습니다. 먼저 프리픽스를 고치세요. 전달은 서로 맞지 않는 주소와 마스크를 구해주지 않습니다.

파서가 실제로 불평하는 것

주소와 마스크로 쓴 목적지는 네트워크를 설명해야 하고, 네트워크는 영으로 채워진 호스트 비트로 시작합니다. 제공한 주소가 아직 호스트 부분에 값을 담고 있으면 그 쌍은 내부적으로 모순됩니다. 172.20.130.0은 영으로 끝나서 깔끔해 보이지만 네 번째 옥텟의 영만이 중요한 것은 아닙니다. 여기서 딴 길로 샌 비트를 가진 쪽은 세 번째 옥텟입니다.

도구마다 이 모순을 다르게 처리합니다. 엄격한 파서는 줄을 거부하고 호스트 비트를 지목합니다. 관대한 파서는 주소를 마스크해 요청하지 않은 것을 설치하며, 이는 더 나쁩니다. 설정이 이제 의도한 적 없는 범위를 라우팅하기 때문입니다. Python의 ipaddress 모듈은 선택을 그대로 드러냅니다. 엄격한 네트워크 파싱은 오류를 내고 strict=False는 호스트 비트를 마스크합니다. 클라이언트가 버전에 따라 엄격하거나 관대하거나 일관성이 없을 수 있으니 습관을 믿지 말고 메시지를 읽으세요.

예를 손으로 풀어 보기

터널이 /20 마스크로 172.20.130.0에 도달해야 한다고 합시다. /20은 세 번째 옥텟에서 네 비트를 빌리므로 그 옥텟은 0, 16, 32, 240처럼 16 단위로만 셉니다. 값 130은 128과 143 사이에 있으므로, 그것을 감싸는 네트워크는 172.20.128.0에서 시작하며, 마지막 옥텟을 영으로 만든 172.20.130.0이 아닙니다.

글로 쓰면 블록은 172.20.128.0에서 172.20.143.255까지이며 4,096개의 주소를 담습니다. 같은 값을 엄격하지 않은 파서에 넣으면 파서가 대신 했을 치환을 보여 줍니다.

$ python3 -c "import ipaddress; n=ipaddress.ip_network('172.20.130.0/20', strict=False); print(n, n.num_addresses)"
172.20.128.0/20 4096

실제로 어떤 목적지를 의도했는지 결정하기

거부된 줄은 보통 세 가지 의도 중 하나를 숨기며, 선택은 여러분만 할 수 있습니다. 터널에 블록 전체가 필요하면 정식 네트워크 주소인 172.20.128.0/20을 쓰세요. 터널에 130 세그먼트만 필요하면 마스크가 틀렸고 172.20.130.0/24가 정직한 형태입니다. 대상이 단일 머신이라면, IPv4 호스트 경로는 /32이며 마스크 산술은 관여하지 않습니다.

각각 다른 양의 트래픽을 허용하며, 불만이 멈출 때까지 마스크를 넓히지 말아야 하는 진짜 이유가 이것입니다. /16은 거의 어디서나 줄을 받아들이고 터널로 라우팅할 의도가 없던 목적지로 트래픽을 보냅니다. 의도에 맞는 가장 좁은 프리픽스를 쓰고, 기대하는 다음 홉에 대해 확인하세요. 파서의 침묵에 대해서가 아닙니다.

전달이 해결책이 아니었던 이유

거부된 경로는 전달 경로에 결코 도달하지 않으므로 net.ipv4.ip_forward을 전환해도 결과가 바뀌지 않습니다. 그 설정은 나중에 호스트가 인터페이스 사이로 패킷을 넘겨야 할 때 중요하며, 테이블이 올바르기 전에 켜면 다음에 어느 단계가 실패할지만 바뀝니다.

같은 지점에서 흔히 두 가지가 더 비난받습니다. 경로가 받아들여져도 더 구체적인 경로에 질 수 있고, 방화벽 규칙이 올바른 조회 후에 트래픽을 버릴 수 있습니다. 단계를 분리하세요. 구문, 설치, 선택, 필터링입니다. 잘못된 단계에서 일하면 생산적으로 느껴집니다. 모든 변경이 무언가를 다시 시작하기 때문입니다.

설치된 경로와 그것이 이기는 길 확인하기

클라이언트가 줄을 받아들이면 무엇을 설치했는지, 커널이 블록 안의 대표 주소에 대해 어느 경로를 고르는지 보세요. 설치된 프리픽스가 쓴 것과 다르면 정규화기가 대신 동작한 것입니다.

블록 안의 구성원 주소와 블록 밖의 주소를 함께 질의해, 안심시키는 한 줄이 아니라 의미 있는 비교가 되게 하세요.

ip -4 route show 172.20.128.0/20
ip -4 route get 172.20.140.10
ip -4 route get 172.20.200.10

프리픽스가 맞다면 세 번째 질의는 터널 밖으로 떨어져야 하고, 그렇지 않다면 만든 경로가 생각보다 넓습니다. 다음 설정을 건드리기 전에 프리픽스가 무엇을 덮어야 했는지 기록하세요. 파싱되는 경로와 동작하는 길은 계속 별개의 관찰이기 때문입니다.