VPN 브리지 스크립트가 여전히 brctl을 호출하는 이유와 의미

터널 클라이언트는 설치되어 있고 프로필도 유효하지만, 도우미는 여전히 brctl이라는 명령에서 실패합니다. VPN 패키지를 다시 설치해도 해결되지 않습니다. 빠진 프로그램은 터널의 일부가 아니라 로컬 브리지 스크립트의 일부이기 때문입니다. 그 스크립트는 현재 시스템이 더 이상 기본으로 제공하지 않는 도구를 요구합니다. 두 문제가 관련 있어 보이는 것은 스크립트가 연결 시점에 실행되기 때문일 뿐입니다.

도우미 프로그램 부재는 터널 결함이 아니다

정확한 호출과 그 환경부터 확인하십시오. 대화형 셸에 있는 명령이 서비스의 제한된 검색 경로에는 없을 수 있으므로 «찾을 수 없음» 오류는 두 가지 다른 의미일 수 있습니다. 서비스 사용자로 command -v brctl 을 실행하고, 스크립트를 시작하는 유닛을 읽으십시오 systemctl cat openvpn-bridge-helper 또는 그에 상응하는 명령으로 확인하십시오. 오류 문구는 보통 빠진 바이너리 이름을 지목하며, 그 이름이 해결해야 할 의존성입니다.

터널 클라이언트를 다시 설치하면 터널이 제공될 뿐 브리지 유틸리티가 제공되는 것은 아닙니다. 둘은 유지 관리자가 다른 별개의 패키지입니다.

brctl이 하던 일과 폐기된 이유

이 도구는 Linux Ethernet 브리지를 만들고 관리했습니다. addbr 는 브리지를 만들고 addif 는 포트를 연결했습니다. Debian 설명서는 이를 폐기로 표시하고 더 많은 것을 다루는 iproute2 브리지 도구를 가리킵니다. 폐기되었다고 해서 어디에서나 제거된 것은 아니며, 더 새로운 도구가 있다고 해서 스크립트의 문자 그대로의 brctl 호출이 성공하는 것도 아닙니다.

따라서 질문은 brctl이 좋은가가 아닙니다. 스크립트가 여전히 유지 관리되는지, 그리고 배포판이 이에 대해 어떤 패키지를 제공하는지가 질문입니다.

두 가지 정직한 선택: 유지 또는 이전

유지란 배포판의 지원 패키지에서 문서화된 의존성을 설치하고 스크립트의 출처, 예상 버전, 실행 경로를 확인하는 것입니다. 그것은 빠진 실행 파일을 만족시킬 뿐 그 밖의 것은 아닙니다. 스크립트의 브리지 이름, 주소 계획, 정리 동작은 검증되지 않은 채 남습니다. 이전이란 지원되는 네트워크 구성에 맞게 의도된 작업을 다시 작성하는 것입니다. 브리지 생성, 포트 연결, 호스트 주소 지정, 링크 활성화는 네 가지 별개의 변경이며, brctl에서 다른 유틸리티로의 셸 별칭은 번역이 아닙니다.

iproute2 대응은 짧습니다. ip link add name br-vpn type bridge 가 브리지를 만들고 ip link set tap0 master br-vpn 가 포트를 연결합니다.

어떤 선택을 했는지, 스크립트의 소유자가 누구인지 적어 두십시오. 두 도구를 모두 호출하는 반쯤 이전된 도우미는 둘 중 어느 쪽보다도 나쁩니다.

둘 중 어느 것을 택하기 전에 브리지 설계를 보십시오

Ethernet 브리지는 Ethernet 전달과 TAP 피어가 필요한 설계에 어울립니다. 브리지 유틸리티를 설치한다고 라우팅된 TUN 연결이 브리지가 되지는 않으며, 지원되는 라우팅 프로필을 무관한 스크립트에 맞추려고 구부려서는 안 됩니다. 프로필이 라우팅한다면 브리지 도우미가 애초에 왜 실행되는지 밝혀내십시오.

실제 브리지를 건드리기 전에 관리 경로를 보존하고 네트워크 구성의 단일 소유자를 확인하십시오.

그런 다음 의존성을 고친 뒤 다음 오류를 읽으십시오. 로컬 브리지 설정, 원격 인증, 결과를 통과하는 허용 트래픽은 세 가지 별개의 결과이며, 그중 하나만 brctl에 관한 것이었습니다.