macOS의 OpenVPN TAP: 디버깅 전에 클라이언트를 확인하십시오

오래된 프로필이 최신 Mac에 들어오고, 클라이언트는 아무 불평 없이 가져오며, 연결은 끊기거나 트래픽이 전혀 지나가지 않습니다. 인증서에 오후를 통째로 쓰기 전에 프로필의 장치 줄을 읽어 보십시오. 거기에 dev tap라고 적혀 있다면 클라이언트에 이더넷 방식 인터페이스를 요구하는 것이고, macOS에서는 이런 세션 대부분이 바로 그 요구에서 끝납니다.

1단계: 프로필이 정말 TAP을 요구하는지 확인하십시오

프로필은 이름이 바뀌고 포장되고 다시 내보내지므로, 실제로 가져온 파일을 확인하십시오. 장치 지시문과 그것을 덮어쓸 수 있는 모든 include를 찾으십시오. 대부분의 경우 출력 두 줄이면 답이 나옵니다. dev와 dev-type이 모두 나타나면 뒤의 지시문이 이기며, 복사된 프로필은 바로 그런 세부를 숨깁니다.

grep -nE "^[[:space:]]*(dev|dev-type)[[:space:]]" client.ovpn
ls -l ~/Library/Application\ Support/ 2>/dev/null

파일에 dev tap 또는 dev tap0이 있으면 클라이언트는 TAP 인터페이스를 구현해야 합니다. dev tun이 있으면 이 글의 나머지는 적용되지 않으며 문제는 다른 곳에 있습니다.

클라이언트 이름과 버전, macOS 버전, 프로필이 어디서 왔는지 적어 두십시오. 이 세 가지가 아래 두 경로 중 무엇이 애초에 가능한지를 결정합니다.

2단계: 장치 모드가 실제로 무엇을 바꾸는지 아십시오

TUN 인터페이스는 IP 패킷을 나릅니다. 클라이언트는 IP 피어로 향한 패킷을 읽고 쓰며, 운영체제는 다른 인터페이스와 마찬가지로 이를 라우팅합니다.

TAP 인터페이스는 이더넷 프레임을 나르며 브로드캐스트와 ARP도 포함합니다. 이것이 브리지 서버가 DHCP로 주소를 나눠 주고 클라이언트가 소리쳐 장치를 찾게 해 주며, 그래서 일부 오래된 설계가 여기에 의존합니다.

대가는 TAP이 시스템에 이더넷 인터페이스를 제시하는 드라이버를 필요로 한다는 점입니다. Apple은 오래된 Mac TAP 드라이버가 기대던 커널 확장 모델을 폐기했고, 그 대체 API가 사용하도록 한 번도 업데이트되지 않은 클라이언트 안에서 마법처럼 나타나지는 않습니다. 플랫폼의 능력과 출하된 제품은 다른 것입니다.

3단계: 호환 클라이언트와 마이그레이션 중에서 고르십시오

정직한 길은 두 가지입니다. 첫째는 게시자가 당신의 macOS 버전과 하드웨어에 대해 필요한 TAP 구성이 지원된다고 밝힌 클라이언트입니다. 사 년 전 포럼 글이나 보관된 설치 파일이 아니라, 현재의 선언과 테스트 연결입니다.

둘째는 서비스를 TUN으로 옮기는 것이며, 이는 클라이언트 변경만큼 서버 변경이기도 합니다. 라우팅된 토폴로지, 주소 풀, 원격 네트워크용으로 푸시되는 경로, 그리고 그 네트워크에서 풀로 돌아오는 경로가 필요합니다.

통하지 않는 것은 로컬 복사본에서 tap 값을 tun 값으로 바꾸고 기대하는 것입니다. 서버는 여전히 브리지하고, 클라이언트는 이제 IP를 말하며, 아무것도 맞지 않습니다.

4단계: 작동 중인 서비스를 바꾸기 전에 사실을 모으십시오

원본 프로필은 그대로 두고 실험용 복사본을 만드십시오. 일 분 안에 되돌릴 수 있는 파일은 정리된 폴더보다 값집니다. 대체가 작동하면 목록에서 똑같이 보이는 프로필 두 개를 남기지 말고 복사본을 일부러 지우십시오. 그 습관 하나가 실패한 마이그레이션 뒤의 혼란 대부분을 막습니다. 현재 동작을 기록해 터널이 올라오는지, 주소를 받는지, 알려진 호스트 하나에 닿는지, 이름 해석이 되는지라는 변화를 증명하십시오.

게이트웨이 소유자에게 세 가지를 물으십시오. 서버가 브리지 토폴로지입니까, 라우팅 토폴로지입니까? 어떤 원격 프리픽스에 닿아야 합니까? 그리고 구성을 바꿀 유지보수 시간대가 있습니까, 아니면 서버를 건드리지 않고 동작해야 합니까?

그 답이 오늘 오후에 클라이언트 문제를 푸는지, 다음 주에 네트워크 변경을 계획하는지를 결정합니다.

5단계: 양쪽 끝에서 마이그레이션을 검증하십시오

서버에 라우팅 구성이 있고 당신에게 맞는 프로필이 있으면 터널이 맺어지고, 클라이언트가 새 풀에서 주소를 받고, 원격 쪽 호스트가 응답하며, 푸시된 DNS 설정으로 이름이 해석되는 순서로 시험하십시오.

다음으로 예전에 이더넷 동작에 의존하던 것을 시험하십시오. 앱이 브로드캐스트로 장치를 찾았다면 라우팅된 터널 너머로는 찾지 못하며, 클라이언트 설정을 아무리 바꿔도 되돌아오지 않습니다. 그 앱에는 알려진 주소, 로컬 보조 호스트, 또는 다른 발견 방법이 필요합니다.

첫 시도에서만 작동하는 프로필은 보통 푸시된 경로나 DNS 설정이 재연결 때 적용되지 않는다는 뜻이므로 재연결과 재부팅을 한 번씩 하고 끝내십시오.

그래도 실패하면 첫 오류를 읽으십시오

인터페이스를 만들지 못하는 클라이언트는 보통 로그 첫 줄들에서 그렇게 말합니다. 인터페이스를 만들고 나서 인증에 실패하는 클라이언트는 장치 문제를 이미 한참 지났으며, TAP을 계속 쫓는 것은 세션을 낭비하는 일입니다.

대체가 증명될 때까지 원본 프로필과 작동하는 구성을 보관하십시오. 클라이언트 변경을 되돌리는 것은 빠르지만, 누군가 짐작으로 뜯어낸 브리지 네트워크를 다시 짓는 것은 빠르지 않습니다.