머신 전체 없이 앱 하나만 VPN으로 보내는 방법

클라이언트 아이콘은 연결됨이라고 하고, 인터페이스도 존재하는데, 애플리케이션은 여전히 아무 데도 닿지 못합니다, 이런 조합은 흔합니다. 가상 인터페이스는 원격 피어나 주소, 경로가 빠져 있어도 계속 존재할 수 있기 때문입니다. ip link 는 올바른 첫 도구이며, 동시에 가장 과대 해석하기 쉬운 도구입니다. 플래그와 카운터는 한 계층만 설명하고, 그 위의 계층은 독립적으로 실패합니다. 터널이 올라와 있다는 것을 증명하려 할 때 인용되는 도구이기도 한데, 바로 그 주장을 이 도구만으로는 뒷받침할 수 없습니다.

아이콘을 읽기 전에 인터페이스를 읽으세요

다음으로 시작하세요: ip -details link show dev tun0 — ip-link 설명서 에 설명된 대로이며, 관례적인 이름 대신 클라이언트가 실제로 가진 인터페이스를 넣으세요. 플래그, 유형, MTU, 인터페이스 정체성은 유용한 관찰입니다. 가상 인터페이스의 상태 문구가 물리 케이블의 반송파 표시처럼 동작해야 하는 것은 아니므로, UP을 터널이 아니라 인터페이스에 대한 진술로 받아들이세요.

그 구분이 가장 혼란스러운 사례를 설명합니다, 원격 쪽이 다시 연결 중이거나 도달할 수 없어도 인터페이스는 남습니다.

지속성 설정은 재연결 때 다시 만들지 않도록 링크를 남겨 둘 수 있습니다, 즉 존재가 곧 건강은 아닙니다.

카운터와 그것을 써야 할 요청을 추가하세요

지원되는 통계 보기인 ip -s link show dev tun0 를 사용해 양방향 패킷과 바이트 카운터를 기록하세요. 그다음 인터페이스를 지나야 할 무해한 요청을 만들고 해당 방향을 비교하세요. 다른 앱의 직접 경로로 간 요청은 이 카운터를 움직이지 않으며, 그것이 이 연습의 요점입니다.

송신 카운터는 움직이는데 수신 카운터가 움직이지 않으면, 패킷은 나갔지만 아무것도 돌아오지 않은 것입니다. 이것은 아무것도 나른 적 없는 인터페이스와 다른 문제입니다. 두 카운터가 모두 움직이는데 앱이 여전히 실패하면 결함은 인터페이스 위에 있고, 그것은 막다른 길이 아니라 진전입니다.

스냅숏 하나를 믿지 말고, 읽기를 전과 후 두 번 하세요.

주소와 경로는 별개의 단계입니다

링크는 프리픽스, 리졸버 구성, 또는 앱에 필요한 경로가 없어도 존재할 수 있습니다. 주소는 ip address show dev tun0 로 확인하고, 목적지가 어느 경로를 고를지는 ip route get 로 실제 대상에 대해 확인하세요. 이 세 관찰은 서로 다른 세 질문에 답하며, 마지막 하나만 포워딩에 관한 것입니다.

IPsec에서는 보안 정책과 연결 상태도 중요할 수 있고, 모든 IPsec 설계가 단순한 tun 인터페이스로 나타나지는 않습니다. 존재할 리 없던 tun 장치를 찾는 것은 잘못된 결론에 빨리 도달하는 방법입니다.

보관하는 모든 출력에 정확한 이름, 네임스페이스, 시간을 기록하세요, 다른 컨테이너나 복원된 세션에서 같은 이름은 전혀 다른 맥락을 나타냅니다.

확인하지 않은 것을 삭제하지 마세요

낯선 인터페이스가 자동으로 오래된 것은 아닙니다. 무엇이든 제거하기 전에 소유자를 확인하고, 제거가 정말 의도된 때에는 클라이언트의 문서화된 해제 절차나 관리되는 구성을 사용하세요. 무슨 일이 일어나는지 보려고 살아 있는 터널을 삭제하는 것은 아무도 묻지 않은 질문에 답하는 시험입니다.

인터페이스가 컨테이너 런타임이나 직접 만들지 않은 네트워크 네임스페이스에 속한다면 소유자는 명령 하나 거리에 있고, 먼저 찾을 가치가 있습니다.

같은 주의는 ip link set down 에도 적용됩니다, 되돌릴 수 있어 보이지만 자주 그렇지 않습니다.

점검에서 남겨야 할 것

좋은 점검은 네 가지 사실로 끝납니다, 인터페이스의 이름과 네임스페이스, 플래그와 MTU, 실제 요청에서 나온 카운터 차이, 그리고 앱이 정말 필요로 하는 경로와 주소입니다. 이것이 적혀 있으면 다음 단계는 명백하고 특정 계층에 속합니다. 없으면 이후의 모든 변경은 롤백 계획이 딸린 추측입니다.

그 네 사실을 동작하는 세션의 같은 네 사실과 비교하세요. 인터페이스 이름과 네임스페이스가 맞는데 카운터 차이가 영이면 요청은 터널에 닿지 않았습니다. 카운터 차이가 건강한데 경로가 다른 곳을 가리키면 터널은 정상이고 라우팅이 아닙니다. 그 비교가 출력 더미를 결정으로 바꿉니다.

출력은 티켓과 함께 보관하세요, 나중의 비교는 무엇이 바뀌었는지 볼 수 있을 때만 유용합니다.

그런 다음 앱을 다시 시험해 고리를 닫으세요, 사용자가 신경 쓴 것은 인터페이스가 아니었으니까요.