TUN/TAP: 잘못된 인수 — OpenVPN 프레이밍 불일치

클라이언트가 인증을 통과하고 로그는 연결됨이라고 말하지만, 어떤 패킷도 터널을 지나지 않습니다. 서버는 write to TUN/TAP: Invalid argument (code=22) 로 시도를 끝내는데, 이는 드라이버 결함처럼 보이지만 보통 그렇지 않습니다. 라우터와 소형 Linux 서버에서 이 줄은 대개 두 피어가 데이터 패킷의 프레이밍 방식에 합의하지 않았다는 뜻이므로, 커널이 전달받은 복호화된 버퍼를 거부합니다. 그 시점에는 라우팅이 아직 테스트되지 않았습니다.

올바른 라우팅 테이블과 깨진 프레이밍 합의는 클라이언트 쪽에서 똑같이 보입니다. 연결됨, 그리고 아무것도 작동하지 않습니다.

터널은 올라오지만 아무것도 지나지 않는다

터널 장치의 쓰기 오류는 복호화 후 라우팅 전에 발생합니다. 데몬이 패킷을 복호화해 인터페이스에 넘기면, 버퍼가 그 장치가 기대하는 것과 맞지 않아 인터페이스가 거부합니다. 코드 22는 잘못된 인수에 대한 일반적인 응답이므로, 유용한 정보는 계층입니다. 이것은 핸드셰이크가 아니라 데이터 경로입니다. 어제는 트래픽이 통했는데 구성 변경 없이 오늘 멈췄다면, 네트워크를 의심하기 전에 기본값을 옮긴 패키지나 펌웨어 업데이트를 의심하세요.

첫 오류 대신 데이터 채널 설정 주변의 로그를 읽으세요. 협상된 압축 모드, dev 유형, 푸시된 옵션이 모두 더 높은 상세 수준에서 나타나며, 세 가지 불일치 중 어느 것인지 알려줍니다.

압축은 프레이밍이지 대역폭이 아니다

압축이 활성화되면 모든 데이터 패킷은 인코딩 방식을 설명하는 헤더를 가지며, 양쪽 끝이 그 헤더에 합의해야 합니다. 오래된 샘플 구성의 comp-lzo 를 여전히 가진 서버가 압축 줄이 없는 클라이언트와 짝을 이루면 정확히 이 오류가 발생합니다. 서버는 클라이언트가 작성한 적 없는 헤더를 기대합니다. comp-lzo 와 compress lz4-v2 를 섞는 것도 같은 방식으로 실패합니다. 둘 다 압축이라고 불리지만 알고리즘이 다르기 때문입니다. 현대 링크에서 이 옵션은 대역폭 기능이 아니라 프레이밍 계약입니다.

버전 동작에는 함정이 있습니다. 2.5 계열은 압축 옵션에 대한 사용 중단 경고를 내기 시작했고, 2.6 은 압축된 패킷을 거부하는 것과 데이터를 압축하지 않은 채 두는 것 사이에 선을 긋습니다. 따라서 라우터 펌웨어 업데이트가 누구도 터널을 편집하지 않은 채 실효 합의를 바꿀 수 있습니다.

양쪽 끝을 맞추거나 양쪽에서 제거하라

모든 압축 지시문을 열거하세요. 서버 파일, 푸시된 옵션, 클라이언트별 파일, 클라이언트 프로필입니다. 서버의 comp-lzo 는 클라이언트에도 같은 단어가 필요하고, adaptive 는 이전 빌드에서 맨 옵션이 보통 의미하는 레거시 기본값입니다. LZO 또는 압축이라고 표시된 라우터 GUI 스위치도 같은 옵션을 쓰므로, 알고리즘을 섞지 말고 일치하도록 설정하세요. 비슷해 보이는 이름이 호환된다고 가정하지 마세요.

압축을 원하지 않으면 양쪽 끝에서 의도적으로 제거하세요. 서버의 allow-compression no 는 압축된 패킷을 거부하지만, 클라이언트가 제공을 중단한 뒤에만 그렇습니다. 클라이언트가 아직 압축을 푸시하는 동안 적용하면 반대 방향으로 불일치가 다시 생깁니다.

푸시와 장치 유형을 확인하라

서버는 기본 파일이나 클라이언트별 파일에서 압축 지시문을 푸시할 수 있고, 클라이언트는 pull-filter 로 푸시된 옵션을 버릴 수 있습니다. 상세 수준 4에서 클라이언트 하나를 연결하고, 서버가 알린 것과 클라이언트가 받아들인 것을 비교해 읽은 다음, 어떤 필터도 그것을 제거하지 않았는지 확인하세요. 양쪽이 이제 합의하는데도 오류가 남으면, 장치 유형을 확인하세요: 한쪽의 dev tap 와 다른 쪽의 dev tun 는 프레임을 교환할 수 없고 커널도 같은 방식으로 쓰기를 거부합니다.

브리지된 TAP 배포에는 다른 장치 이름만이 아니라 서버의 실제 브리지가 필요합니다. 인터페이스를 브리지에 추가하지 않고 tap0 로 이름을 바꾸면 쓰기를 받아들이고 아무 데도 가지 않는 장치가 됩니다.

그런 다음 클라이언트 하나와 목적지 하나로 검증하세요. 서버의 터널 주소에 ping하고, 다음으로 그 LAN의 호스트에 ping하세요. 첫 번째는 데이터 채널을, 두 번째는 포워딩을 증명합니다.