처음부터 마지막까지의 IP 범위를 정확한 VPN 경로로 바꾸기

누군가 처음과 마지막 주소를 주고 VPN 경로를 요청합니다. 유혹적인 선택은 두 끝을 모두 포함하는 가장 짧은 프리픽스를 고르는 것이지만, 그 선택은 아무도 요청하지 않은 목적지를 조용히 추가합니다. CIDR 블록은 항상 둘의 거듭제곱 크기와 그에 정렬된 시작 주소를 가지므로, 임의의 범위에는 보통 하나로 부족합니다. 범위를 따라가며 정확히 나누고, 그 바로 바깥의 주소를 확인하세요.

프리픽스가 아니라 범위에서 시작하세요

다른 무엇을 쓰기 전에 첫 주소와 마지막 주소를 적어 두세요. 그 쌍이 요구 사항이며, 프리픽스는 그 가능한 표현 중 하나일 뿐이고 때로는 틀린 표현입니다. 두 숫자는 마스크보다 훨씬 확인하기 쉽습니다.

정렬된 범위는 하나의 블록으로 접힙니다. 정렬되지 않은 범위는 여러 개로 분해되며, 그 분해는 근사가 아니라 정확합니다. 해서는 안 되는 일은 바깥으로 반올림하고 충분히 가깝다고 부르는 것이며, 추가 주소는 경로가 지닌 정책을 그대로 받기 때문입니다.

오류의 두 방향이 모두 중요합니다. 터널로 들어가는 경로에서는 추가 주소가 VPN으로 끌려 들어갑니다. 우회 예외에서는 추가 주소가 그것을 건너뜁니다. 어느 결과도 설치한 프리픽스만 보여 주는 라우팅 테이블에는 나타나지 않습니다.

첫 번째 경우: 범위가 우연히 정렬되어 있음

198.51.100.64부터 198.51.100.127까지를 봅니다. 첫 주소가 64개 주소 경계에 정렬되어 있고 범위가 정확히 64개 주소이므로, 하나의 /26이 남김없이 그것을 설명합니다.

이것은 쉬운 경우이며 요구 사항이 이미 프리픽스로 생각하던 사람에 의해 작성되었을 가능성이 높기 때문에 알아 둘 가치가 있습니다. 확인도 짧아서 크기가 둘의 거듭제곱이고 시작이 그 크기의 배수인지 확인하면 됩니다.

문서용 범위가 좋은 예가 되는 이유는 아무도 그것을 소유하지 않기 때문입니다. 이 주소를 실제 터널에 설치하지 말고, 낯설어 보인다는 이유만으로 주어진 범위를 문서용 공간이라고 가정하지 마세요.

두 번째 경우: 정렬되지 않았으므로 나누기

이제 198.51.100.100부터 198.51.100.107까지를 봅니다. 여덟 개 주소이며 둘의 거듭제곱이지만, 100은 여덟의 배수가 아닙니다. 그 크기의 블록 하나는 거기서 시작할 수 없으므로 범위를 둘 이상으로 덮어야 합니다.

정확한 덮개는 두 개의 /30 블록입니다: 198.51.100.100/30이 100부터 103까지를 덮고, 198.51.100.104/30이 104부터 107까지를 덮습니다. 모두 여덟 개 주소이고 범위 밖은 없으며, 분해는 주어진 범위에 대해 유일합니다.

python3 -c "from ipaddress import ip_address, summarize_address_range as s; print(*s(ip_address('198.51.100.100'), ip_address('198.51.100.107')), sep='\n')"

표준 라이브러리 함수가 계산을 대신 해 주고, ipaddress 문서가 무엇을 반환하는지 정의합니다. 그것이 하지 않는 일은 게이트웨이를 고르거나, 주소의 소유자를 정하거나, 그 뒤의 어떤 서비스에도 접근을 허용하는 것입니다.

더 넓은 프리픽스가 무엇을 잡았을지 측정하세요

지름길을 받아들이기 전에 비용을 계산하세요. 198.51.100.96에서 시작하는 /28은 96부터 111까지를 덮으며, 여덟 개가 아니라 열여섯 개 주소입니다. 추가된 여덟 개는 96부터 99까지와 108부터 111까지이고, 그 모두가 경로를 물려받습니다.

python3 -c "from ipaddress import ip_network as n; w=set(n('198.51.100.96/28')); t=set(n('198.51.100.100/30'))|set(n('198.51.100.104/30')); print(len(w), len(t), sorted(w-t))"

여덟 개의 추가 목적지는 변경 요청에 적을 수 있는 구체적인 숫자입니다. 지름길이 받아들일 만한지 결정하는 것도 이 숫자이며, 그것은 산술이 아니라 정책의 문제입니다.

산술과 발견을 분리해 두세요. 네트워크 운영자가 제공한 범위는 정확히 변환됩니다. 변하는 서비스의 DNS 응답 하나로는 그 서비스의 완전하거나 영구적인 범위가 확립되지 않으며, 무관한 이름이 같은 주소를 공유할 수 있습니다.

정확한 집합을 설치하고 가장자리를 검증하세요

얻은 각 프리픽스를 VPN 구성의 소유자에게 넘기고 지원되는 방식으로 설치하게 하세요. 요구 사항에 두 개의 항목이 필요하면, 양식을 짧게 하려고 하나를 넓히는 대신 두 개의 항목을 유지하세요.

sudo ip route add 198.51.100.100/30 via 10.90.0.1 dev tun0
sudo ip route add 198.51.100.104/30 via 10.90.0.1 dev tun0
ip route get 198.51.100.101
ip route get 198.51.100.97

마지막 두 명령이 사람들이 건너뛰는 것입니다. 첫 번째 내부 주소는 새 경로를 따라야 하고, 범위 바로 바깥의 주소는 따라서는 안 됩니다. 둘 다 같은 길로 간다면 요구 사항과 구성 사이 어딘가에서 범위가 넓어진 것입니다.

첫 주소, 마지막 주소, 그리고 그것을 표현하는 프리픽스를 기록하세요. 다음에 규칙을 검토하는 사람은 산술을 다시 하지 않고 요구 사항과 구성을 대조할 수 있으며, 정확한 경로와 편리한 경로의 차이는 계속 보입니다.