터널의 /32을 복사한다고 사무실 서브넷이 라우팅되지는 않는다

VPN이 연결되고 인터페이스에는 서른두 비트 마스크가 있는 주소가 표시되지만 사무실 서버는 여전히 연결되지 않습니다. 다음 단계는 보통 그 마스크를 경로에 다시 사용하는 것입니다. 인터페이스가 터널이 도달할 수 있는 범위를 설명한다는 이론입니다. 그렇지 않습니다. 그 주소는 지점 간 링크의 로컬 끝을 설명하며, 관심 있는 목적지는 그 반대편의 다른 접두사에 있습니다.

서로 다른 두 가지가 혼동되고 있습니다. 터널이 준 주소와 그것을 통해 도달하려는 네트워크입니다.

두 주소, 두 가지 일

지점 간 터널에서 클라이언트 주소는 흔히 단일 호스트 주소입니다. 링크의 반대편에 정확히 하나의 피어만 있기 때문입니다. 공유 세그먼트도 ARP도 없으므로 Ethernet에서 터무니없어 보일 마스크가 여기서는 완전히 정상입니다.

목적지 접두사는 사무실 네트워크에 대한 사실이며 터널에 대한 것이 아닙니다. 서버 하나가 필요하면 경로는 그 서버에 대한 호스트 경로입니다. 사무실 서브넷 전체가 필요하면 경로는 그 서브넷입니다. 어느 답도 인터페이스에서 읽을 수 없으며, 터널 주소 옆에 나타났다는 이유로 하나를 고르는 것이 작동하는 설정을 깨뜨리는 방법입니다.

그 세 번째 행이 낙관이 중단으로 바뀌는 지점입니다. 한 사이트만 서비스하는 터널로 전체 사설 범위를 라우팅하면 무관한 트래픽이 전달할 수 없는 경로로 밀려나고, 그 결과 생기는 장애는 너무 넓은 경로가 아니라 고장 난 VPN처럼 보입니다.

요구 사항에서 접두사를 고르십시오

프로필을 건드리기 전에 요구 사항을 한 문장으로 적으십시오. 어떤 호스트에 도달할 수 있어야 하며, 그것을 덮는 가장 좁은 접두사는 무엇입니까? 서버 하나는 호스트 경로입니다. 서브넷은 서브넷 경로입니다. 서브넷 범위는 요약이며, 요약은 그 안의 모든 주소에 도달할 수 있다는 약속인데 이는 좀처럼 사실이 아닙니다.

그다음 숫자를 사무실이 실제로 사용하는 것과 대조하십시오. 사이트의 주소 계획과 확인하지 않고 채팅 메시지에서 접두사를 복사하는 것이 경로가 아무도 소유하지 않은 서브넷을 가리키게 되는 이유입니다.

경로는 길이지 권한이 아니라는 점도 기억하십시오. 게이트웨이는 여전히 클라이언트가 목적지를 사용할 수 있는지 결정하며, 서비스는 여전히 거절할 수 있습니다. 경로를 올바르게 설치하면 패킷이 그곳에 도착하지만 권한 부여에 대해서는 아무것도 답하지 않습니다.

프로필에 추가하고 절대 교체하지 마십시오

NetworkManager 프로필의 경로는 다중 값 속성이며, 설정과 추가의 차이는 한 문자입니다. 더하기 형식을 사용하여 항목을 추가하고 이미 저장된 모든 것을 유지하십시오.

nmcli connection modify uuid 11111111-2222-4333-8444-555555555555 \
  +ipv4.routes "10.40.20.9/32"

더하기가 없으면 할당이 전체 목록을 교체합니다. 이미 여러 접두사를 가진 프로필에서는 작동하던 접두사가 조용히 삭제되며, 증상은 나중에 이 노트북에서 예전에 도달할 수 있었던 서비스로 나타납니다.

이름 대신 UUID를 사용하십시오. 복원 후 이름이 중복되며, 편집하는 연결이 트래픽을 운반하는 연결이 아닐 수 있습니다. 먼저 동일한 항목이 있는지 확인하십시오. 중복 추가는 무해하더라도 지저분합니다.

이 경로 속성 참조 는 설치된 버전의 목적지, 선택적 다음 홉, 메트릭, 속성 구문을 문서화합니다. 다음 홉을 추가하기 전에 읽어 보십시오. 필요한지 여부는 통합과 토폴로지에 달려 있으며, 인터페이스 목록의 첫 주소에서 추측하는 것은 방법이 아닙니다.

기본 경로와 DNS는 별개의 결정입니다

Adding an office prefix says nothing about where the rest of your traffic goes. If policy requires ordinary internet traffic to stay outside the tunnel, that is the ipv4.never-default decision, and it belongs to whoever owns the connection policy rather than to whoever is fixing one unreachable server.

자동 경로는 가볍게 건드리지 말아야 할 또 다른 것입니다. 빠진 항목 하나를 해결하려고 억제하면 작동하던 여러 개가 제거될 수 있으며, 그것을 제안한 사람은 보통 다른 푸시가 있는 다른 프로필을 보고 있었습니다.

DNS에는 고유한 경로와 고유한 장애가 있습니다. 잘못된 리졸버를 통해 올바른 주소로 해석되는 이름, 또는 사설 영역에 답할 수 없는 리졸버는 경로가 완벽한데도 라우팅 문제처럼 보입니다. 주소와 이름을 따로 테스트한 다음 실제로 어느 계층이 실패했는지 판단하십시오.

무엇이 적용되었는지 확인하십시오

저장된 수정은 적용된 수정이 아닙니다. 관리자의 지원되는 수명 주기로 다시 연결한 다음 의도한 목적지의 실제 경로와 어떤 테이블을 참조할지 결정하는 정책 규칙을 확인하십시오.

접두사가 있고 연결이 여전히 실패한다면 다른 문제로 넘어간 것입니다. 소스 주소 선택, 원격 끝의 반환 경로, 또는 클라이언트를 거부하는 서비스입니다. 그 각각은 이미 수정한 프로필보다 살펴볼 더 나은 곳입니다.