OpenVPN의 사전 생성 tun: 두 가지 소유 모델 비교

누군가 tun1을 미리 만들었고, 프로필에는 dev tun1이라고 적혀 있지만 연결은 여전히 붙지 않습니다. 호스트에 이름이 있다는 사실만으로는 거의 아무것도 알 수 없는데, 연결은 네임스페이스, 장치 유형, 링크 소유자, 그리고 데몬에 허용된 권한에 달려 있기 때문입니다. 장치를 재사용하면 기본 구성이 감추고 있는 “어떤 구성 요소가 주소와 경로를 기록하는가”라는 결정도 강제됩니다. 두 배치의 실패 방식은 구성 줄보다 훨씬 크게 다르므로, 프로필을 편집하기 전에 결정하십시오.

이름은 연결이 아닙니다

dev tun1은 OpenVPN에 그 이름의 인터페이스를 요청하고, 전통적인 사용자 공간 빌드는 그것을 열려고 시도합니다. 이름이 일반적인 tun 또는 tap 패턴을 따르지 않으면 프로필에는 대응하는 dev-type도 필요한데, 유형은 문자열에서 절대 추론되지 않기 때문입니다. TAP 장치는 라벨만 다른 TUN 장치가 아니어서, 잘못된 것을 붙이면 즉시 실패하거나 아무도 예상하지 못하는 프레임을 나르는 링크가 만들어집니다. 이후의 모든 확인은 양쪽이 그것에 합의한다고 전제하므로, 다른 무엇보다 먼저 유형을 확인하십시오. 그다음 프로세스가 장치를 실제로 열 수 있는지, 단지 볼 수 있는지가 아니라 확인하십시오.

dev tun1
dev-type tun

네트워크 인터페이스와 /dev/net/tun은, 하나는 네임스페이스 안의 링크이고 다른 하나는 사용자 공간 프로그램이 연결에 사용하는 문자 장치라는 점에서 서로 다른 객체입니다. Linux TUN/TAP 문서는 그 연결 경로와 영구 장치의 소유 규칙을 설명합니다. ip link을 실행할 수 있는 root 셸은 셸에 권한이 있다는 것만 증명하며, 데몬에 있다는 것은 증명하지 않습니다. 장치 노드의 소유, 서비스의 기능 집합, 실행 사용자가 모두 맞아야 열기에 성공합니다.

존재하지만 열리지 않는 장치는 소유 문제이지 라우팅 문제가 아닙니다. 디버깅할 때도 그렇게 다루지 않으면, 오후가 결코 문제가 아니었던 라우팅 테이블을 읽는 데 사라집니다.

누가 링크를 구성하는가: 두 가지 소유 모델

첫 번째 모델에서 OpenVPN은 연결을 올리는 과정의 일부로 주소와 경로를 구성합니다. 이것이 기본 동작이며, 하나의 구성 요소가 상태를 만들고 다시 제거하기 때문에 가장 따지기 쉽습니다. 두 번째 모델에서는 외부 관리자가 인터페이스를 소유하고, ifconfig-noexec이 OpenVPN이 주소 구성 명령을 실행하지 못하게 하며 매개변수를 스크립트에 넘깁니다. 그러면 관리자가 올바른 로컬 및 피어 구성을 직접 적용해야 하며, 이는 옵션 이름이 암시하는 것보다 많은 작업입니다. 둘 중 무엇을 고를지는 링크가 올라와 있는 동안 누가 그것을 바꿀 수 있는가의 문제입니다.

ifconfig-noexec은 주소만 다루므로 라우팅 테이블은 그대로 두고, 경로 구성은 route-noexec의 몫입니다. 두 지시문을 서로 다른 소유자를 가진 별개의 제어로 다루어야 하는데, 하나를 설정하고 다른 하나를 가정하는 것이 반쯤 구성된 링크의 흔한 원인이기 때문입니다. 계층마다 정확히 하나의 소유자를 고르고, 주소는 한 곳에, 경로도 한 곳에 두십시오. 네트워크 관리자와 VPN 도우미가 둘 다 주소를 쓰면, 연결이 끊길 때 상대편이 아직 의존하는 상태가 지워집니다.

중요한 네임스페이스에서 장치를 확인하십시오

VPN 프로세스가 실행되는 네임스페이스에서, 셸이 우연히 있는 곳이 아니라, 장치를 확인하십시오. 아래 두 명령은 서로 다른 질문에 답하며, 호스트가 컨테이너는 보지 못하는 인터페이스를 볼 때 그 차이가 드러납니다. 링크가 있는지 먼저 알아야 두 번째가 의미를 가지므로, 주어진 순서대로 실행하십시오.

ip -details link show dev tun1
ip tuntap show

첫 번째 명령은 커널이 보는 그대로 링크를 출력하며 플래그와 인터페이스 유형도 포함되므로, 이것이 의도한 장치인지 확인할 수 있습니다. 두 번째는 영구 tun/tap 항목을 나열하며, 이들은 어떤 프로세스도 붙들지 않은 채 존재합니다. 정해진 소유자를 기다리는 인터페이스는 다른 VPN에 붙은 살아 있는 터널과 다른 상황이며, 두 번째만이 여러분의 연결이 왜 실패하는지 설명합니다. 영구 항목과 사용 중인 인터페이스는 해결책이 다르므로, 무엇이든 바꾸기 전에 장치를 붙들고 있는 프로세스를 찾으십시오.

멀티큐 지원은 자체 요구 사항을 가진 특정 드라이버 배치이며, 무관한 프로세스가 하나의 인터페이스를 공유하라는 허가가 아닙니다. 다른 소유자의 살아 있는 세션은 조정 문제이고, 어떤 프로필 편집도 그것을 해결하지 못합니다.

두 가지 지속성

커널 지속성과 persist-tun은 혼동하기 쉽고 틀리면 비싼 수명을 설명합니다. 영구 장치는 어떤 프로세스와도 독립적으로 존재하므로 중지 후에도 남아 다음 시작에서 재사용할 수 있습니다. persist-tun은 하나의 OpenVPN 프로세스 안에서 지원되는 소프트 재설정을 넘겨 자원을 유지하며, 훨씬 짧은 지평입니다. 둘 다 서비스를 멈추면 경로와 주소가 그 자리에 남는다고 약속하지 않으며, 계속 보이는 인터페이스는 작동하는 암호화 세션의 증거가 아닙니다.

백엔드도 확인해야 하는데, 미리 만든 인터페이스는 어떤 구현이 그것을 열지에 대해 아무것도 말하지 않습니다. 직접 데이터 경로를 가진 커뮤니티 빌드는 설계가 달리 말하지 않는 한 그것을 쓰려고 시도합니다. 버전이 이 스위치를 지원하는 곳에서는 disable-dco이 대신 사용자 공간 경로를 선택하지만, 오래된 엔진과 다른 클라이언트에는 그런 지시문이 없으므로 적용된다고 가정하지 말고 버전 조건을 옵션 옆에 두십시오.

시작만 시험하면 무엇이 깨지는가

소유 합의는 첫 시험을 통과하고 마지막 시험에서 실패할 수 있으며, 그래서 시작만으로는 약한 점검이 됩니다. 대신 소프트 재설정과, 완전 중지 뒤의 시작이라는 두 가지 전이를 관찰하십시오.

systemctl status openvpn-client@lab
ip -details link show dev tun1

시작은 쉬운 경우로, 유닛이 올라오고 링크가 나타나며 상태 출력이 로드된 프로필 이름을 알려 줍니다. 연결은 데몬이 장치를 여는 순간이므로, 유닛이 활성이라고 보고한 뒤에, 그 전이 아니라, 링크 점검을 실행하십시오. 상태가 아직 활성화되는 중인데 링크가 있으면, 아직 아무도 붙지 않은 영구 장치를 보고 있는 것이지 작동하는 터널이 아닙니다. 쓸 수 있는 경로가 없는 연결된 인터페이스도 여전히 실패이므로, 계속하기 전에 링크로 실제 트래픽을 흘려보내십시오.

kill -SIGHUP $(pidof openvpn)
journalctl -u openvpn-client@lab -n 40
systemctl stop openvpn-client@lab
ip -details link show dev tun1

소프트 재설정은 세션을 사용 가능하게, 자원을 온전하게 남겨야 하며, 그것이 persist-tun이 하는 일입니다. 완전 중지는 외부 관리자가 정체를 드러내는 지점으로, 링크나 그 주소가 중지 후에도 살아남으면 소유자는 다른 누군가이며, 그것은 여러분이 문서화한 상태이거나 방금 찾은 버그입니다. 두 관찰을 프로필 옆에 기록해 두어, 다음 변경이 도식이 아니라 증거에서 시작하게 하십시오.