게스트 VPN과 호스트 VPN: 실제로 이기는 경로는 어느 쪽인가

두 클라이언트가 동시에 돌아가고 있고, 둘 다 자기가 기본 경로를 소유한다고 믿는데, 증상은 이상한 형태로 나타납니다: 게스트의 한 애플리케이션은 동작하고 다른 하나는 잘못된 곳으로 해석됩니다. 게스트 안의 VPN과 호스트 위의 VPN은 공존할 수 있지만, 바깥 경로와 안쪽 정책이 누가 무엇을 나르는지에 합의할 때만 그렇습니다. 둘을 함께 시작한다고 해서 저절로 사슬이 생기지는 않습니다. 먼저 연결 방식을 적고, 그다음 한 번에 하나씩 바꾸십시오.

먼저 게스트의 연결 방식을 기록하십시오

게스트는 하이퍼바이저가 준 경로, 즉 호스트 뒤의 NAT, 물리 세그먼트로 가는 브리지, 또는 위에 라우팅을 얹은 호스트 전용 네트워크로 자기 VPN 서버에 도달합니다. 연결 방식이 달라지면 게스트가 볼 수 있는 것과 호스트가 그 트래픽에 할 수 있는 일이 달라집니다. NAT 아래에서는 게스트의 패킷이 호스트에서 오는 것처럼 보이므로, 호스트 자신의 터널이 게스트가 아무것도 모르는 채로 그것들을 나를 수 있습니다. 브리지 아래에서 게스트는 세그먼트에 자기 존재와 자기 기본 게이트웨이를 가집니다.

어떤 구성도 건드리기 전에 연결 방식을 적고, 어느 클라이언트가 어느 애플리케이션을 나를지도 함께 적으십시오. 그 문장이 이런 사안의 대부분을 해결하는데, 두 클라이언트는 보통 서로 다른 가정 위에 만들어지기 때문입니다. 호스트 터널을 쓰도록 기대되는 게스트는 자기 쪽의 경쟁하는 기본 경로도 가져서는 안 됩니다.

게스트의 끝점을 바깥으로 추적하십시오

게스트 VPN은 다른 무엇이 동작하기 전에 자기 서버로 가는 쓸 만한 경로가 필요합니다. 호스트 터널이 올라가 있고 게스트가 NAT 뒤에 있으면, 게스트의 핸드셰이크는 호스트 터널을 통해 나가는데, 그것이 설계인지 아무도 기록하지 않은 사고인지는 알 수 없습니다. 호스트 터널이 끊기고 게스트가 그것에 의존하고 있었다면, 게스트 쪽에는 아무 변화도 없이 게스트는 연결을 잃습니다. 끝점을 바깥으로 추적하면 그 둘 중 어느 쪽인지 알 수 있습니다.

어느 문맥에서든 넓은 경로는 다른 클라이언트가 기대한 트래픽을 붙잡습니다. 게스트 안의 0.0.0.0/0 경로와 전체 터널 호스트 클라이언트는 둘 다 모든 것을 주장하고, 마지막에 적용된 쪽이 이깁니다. 게스트의 가상 네트워크, 로컬 LAN, 원격 네트워크 사이의 겹침은 사설 접두사에 대해 같은 효과를 내고, 실패는 인증 문제처럼 보이며, 주소 변환 동작은 컨테이너 네트워킹에 대해 설명된 것과 같습니다.

변경 전과 후의 기록을 비교하십시오

호스트 터널을 끈 상태나 정책이 허용하는 통제된 상태에서 기준선을 잡고 게스트의 경로와 리졸버를 기록하십시오. 그런 다음 결합 구성을 적용하고 두 기록을 비교하되 프라이버시 요구는 그대로 두십시오. 직접 기준선이 적절하지 않다면 비교를 건너뛰는 대신 그 제약을 기록에 적으십시오.

ip route get 10.20.30.41
ip rule show
resolvectl status --no-pager | head -12

경로 조회는 특정 목적지를 나를 인터페이스와 출발지 주소를 지목하며, 이 조사에서 가장 유용한 한 줄입니다. 규칙 목록은 정책 라우팅이 일부 목적지를 두 번째 테이블로 보내는지 보여 줍니다. 리졸버 출력은 DNS가 게스트 터널을 따랐는지 호스트 경로에 머물렀는지 보여 줍니다. 같은 세 명령을 변경 전과 후에 실행하면 그 차이가 범인을 지목합니다.

재시작을 넘어서도 소유권을 분명히 하십시오

호스트 클라이언트의 로컬 접근 제한은 가상 NAT나 브리지로 가는 트래픽을 막을 수 있고, 그 제한은 흔히 게스트의 자격 증명 문제로 오해됩니다. 테스트를 통과시키려고 제한을 끄는 대신 클라이언트의 문서화된 동작을 읽으십시오. 지원되는 수정을 한 뒤 게스트 애플리케이션과 필요한 실패 정책을 다시 시험하십시오. 성공적으로 다시 연결된 호스트는 게스트의 경로나 리졸버에 대해 아무것도 증명하지 않습니다.

기본 경로를 어느 쪽이 소유하는지 정하고 그것을 운영 문서에 쓰십시오. 게스트의 재시작이나 소유권을 조용히 뒤집는 호스트의 네트워크 전환은 결코 잘못이 없던 VPN에 대한 버그 보고를 낳습니다. 그 배치는 왜 동작했는지 아무도 기억하지 못한 채 재부팅을 견뎌야 합니다.