Docker: VPN 세션 중에 미리 정의된 주소 풀이 남아 있지 않음

실패는 구체적입니다. Docker가 새 브리지 네트워크에 쓸 수 있는 자동 서브넷을 찾지 못하는 것입니다. 머신의 주소가 바닥났다는 뜻도 아니고 VPN이 고장 났다는 뜻도 아닙니다. 진단을 좌우하는 것은 두 가지 질문입니다. 데몬이 어떤 후보 블록을 볼 수 있는지, 그리고 이 환경에서 할당기가 그중 무엇을 제외하는지입니다. 이 순서대로 진행하십시오. 첫 번째 질문에 답하기 전에는 두 번째 질문이 의미가 없습니다.

무엇이든 바꾸기 전에 무엇이 실패했는지 확인하십시오

아래 단계는 데몬을 실행하는 호스트에서 수행하십시오. 원격 컨텍스트와 대화하는 셸은 다른 머신을 설명하고 있으며, 그 실수 하나로 한 시간을 낭비할 수 있습니다.

동시에 티켓에 Engine 버전을 적어 두십시오. 이 런북의 나머지 모든 휴리스틱은 버전에 종속되며, 버전 없는 주장은 소문입니다.

이미 보유한 할당을 세십시오

네트워크를 나열한 다음 중요한 것을 살펴보십시오. docker network ls 그리고 이어서 docker network inspect NETWORK_NAME 입니다. 각각의 IPAM 서브넷과 연결된 컨테이너를 읽으십시오. 여러 Compose 프로젝트는 컨테이너 수가 시사하는 것보다 더 많은 블록을 소비합니다. 모든 프로젝트가 자체 기본 네트워크를 만들려는 경향이 있기 때문입니다. 중지된 컨테이너는 자기 네트워크의 할당을 해제하지 않습니다.

풀 구성도 확인하십시오. 기본 풀에는 기준 범위와 네트워크당 프리픽스 크기가 있습니다. 네트워크당 큰 할당은 사용 가능한 블록을 더 빨리 소진하며, 이는 용량의 사실이지 라우팅 문제가 아닙니다.

숫자를 적어 두십시오. 다음 변경이 도움이 되었는지 알려 주는 기준선입니다.

데몬이 보는 경로를 비교하십시오

VPN은 후보 선택에 영향을 줄 수 있지만, 방식은 구현에 달려 있습니다. Linux의 Moby 28.2.2에서 InferReservedNetworks는 네임서버 주소와 일부 온링크 IPv4 경로를 수집하며, 모든 테이블의 모든 경로를 단순히 예약하지는 않습니다. 수집된 링크 경로는 지정되지 않은 목적지 주소도 제외하므로 0.0.0.0/1 경로 하나만으로 모든 주소를 예약하지 않습니다. 다른 광범위한 온링크 프리픽스, 예를 들어 128.0.0.0/1은 익숙한 후보 범위 172와 192를 가로지를 수 있습니다.

VPN이 연결되기 전과 후에 ip -4 route show table all를 데몬의 호스트에서 비교하십시오. 차이가 증거이고, 버전이 주장의 범위입니다.

한 릴리스의 휴리스틱을 모든 릴리스에 일반화하지 마십시오. 포럼 답변이 정책 변경이 되는 경로가 바로 그것입니다.

동작하는 가장 작은 수정을 고르십시오

확인된 미사용 네트워크가 필요한 블록을 보유하고 있다면, 광범위하게 잘라내는 대신 소유자와 함께 표적화된 폐기를 계획하십시오. 새 네트워크의 경우 명시적으로 검토된 미사용 서브넷은 자동 선택에 대한 의존을 완전히 피합니다. 그 서브넷도 실제 Docker, LAN, 필요한 VPN 목적지는 피해야 합니다. 사설이 곧 안전은 아니기 때문입니다. 실제 원격 프리픽스를 라우팅하면 할당 오류를 끊긴 접속과 맞바꾸게 됩니다.

default-address-pools를 바꾸는 것은 향후 할당에 관한 더 넓은 정책입니다. 충돌하지 않는 기준과 적절한 할당 크기를 고르고, 기존 데몬 설정과 병합하고, 문서화된 재시작 영향을 계획하십시오. 기존 네트워크가 조용히 다시 번호 매겨지지는 않습니다.

할당을 성공시키려고 회사 경로 푸시를 끄지 마십시오. 명시적 주소 계획은 보통 필수 정책을 약화하지 않고도 국소 문제를 해결합니다.

할당과 라우팅을 따로 받아들이십시오

변경 후 Docker가 실제로 만든 서브넷을 살펴보고 애플리케이션의 VPN 및 로컬 의존성을 시험하십시오. 성공한 할당과 실행 시점의 올바른 라우팅은 서로 다른 두 가지 인수 검사이며, 첫 번째를 통과한 것이 두 번째의 증거는 아닙니다. 앱이 터널 뒤의 리소스에 도달하지 못한다면 풀 오류가 가리고 있던 라우팅 문제가 있는 것입니다. 두 결과를 모두 티켓에 기록하십시오.

경로 차이와 풀 개수를 변경 기록과 함께 보관하십시오. 다음 VPN 클라이언트 업데이트가 Docker를 건드리지 않고 첫 번째를 바꿀 수 있습니다.

다른 사람이 이 두 검사를 반복해 같은 답을 얻을 수 있을 때 런북이 완성됩니다.