OpenVPN TUN과 TAP: 결정하는 세 가지 조건

두 터널이 같은 파일 전송을 운반하면서도 회선에 싣는 내용은 완전히 다를 수 있습니다. 하나는 두 주소 사이에서 IP 패킷을 옮기고, 다른 하나는 이더넷 프레임을 옮기며 세그먼트로 브리지할 수 있습니다. 이 차이가 어떤 애플리케이션이 동작하는지, 어떤 클라이언트가 접속할 수 있는지, 얼마나 많은 네트워크 설계를 떠안을지를 결정합니다.

실제로는 세 가지 조건이 정하며, 순서대로 확인하십시오. 보통 첫 번째 조건에서 논의가 끝납니다.

각 인터페이스가 실제로 운반하는 것

TUN 장치는 3계층 점대점 인터페이스로, 커널이 IP 패킷을 넘기고 터널이 이를 피어 주소로 운반합니다. TAP 장치는 이더넷 프레임을 운반하는 2계층 인터페이스이며, 브리지를 애초에 가능하게 하는 것이 바로 이것입니다. 커널 문서도 그렇게 설명합니다. 둘 다 페이로드의 암호화 방식을 바꾸지 않으며 강도 설정도 아니고, 선택은 양 끝이 무엇을 교환해야 하는지에 관한 것이지 트래픽이 얼마나 잘 보호되는지에 관한 것이 아닙니다.

한 가지 결과가 즉시 따라옵니다. 양 끝이 합의해야 하며, 한 장치 유형에 맞게 구성된 클라이언트는 나머지가 아무리 일치해도 다른 유형에 맞게 구성된 서버에 접속할 수 없습니다.

첫 번째 조건: 두 번째 계층이 정말 필요한가?

브리지는 IP가 아닌 트래픽, 라우터를 넘을 수 없는 검색, 한 세그먼트에 있기를 고집하는 애플리케이션처럼 프로토콜이 정말로 같은 브로드캐스트 도메인을 필요로 할 때 복잡성을 정당화합니다. 나머지는 모두 라우팅 문제이며, 라우팅은 훨씬 적은 장비로 이를 해결합니다. 세그먼트를 넓은 지역으로 확장하면 브로드캐스트도 함께 확장되므로 루프 방지, 주소 계획, 장애 도메인이 모두 설계의 일부가 됩니다. 단일 경로로 충족되었을 요구에 비해 받아들일 것이 너무 많습니다.

테스트는 구체적이어서, 라우팅된 터널에서 실패하는 애플리케이션을 대고 이유를 말하십시오. 브로드캐스트가 필요하다는 답이면 두 번째 계층이 정직한 답입니다. 누군가 서버 하나에 도달하지 못했다는 답이면 요구는 경로나 방화벽 규칙입니다.

두 번째 조건: 클라이언트가 지원하는가?

지원은 일정하지 않습니다. 데스크톱 클라이언트는 보통 두 장치 유형을 모두 제공하지만, 모바일과 임베디드 클라이언트는 흔히 라우팅 모드만 구현하며, 불평 없이 가져온 프로파일도 인터페이스를 만들려 할 때 실패할 수 있습니다. 플랫폼 이름으로 기능을 추측하지 말고 구체적인 클라이언트와 버전을 확인하십시오.

지원되지 않는 옵션 오류는 가져오기가 성공할 때까지 낯선 줄을 지우라는 초대가 아닙니다. 프로파일과 클라이언트가 무엇이 가능한지에 대해 합의하지 않았다는 뜻이며, 수리는 프로파일을 발급한 운영자의 몫입니다. 검증기를 조용히 시키려고 옵션을 제거하면, 제공하려던 속성을 조용히 빠뜨린 채 동작하는 것처럼 보이는 연결이 만들어질 수 있습니다.

세 번째 조건: 정말 인터페이스 문제인가?

인터페이스 문제의 책임은 인접한 두 선택에 돌아갑니다. 가상 장치는 터널에 무엇이 들어가는지를 정하고, UDP인지 TCP인지는 바깥 전송이 어떻게 동작하는지를 정합니다. 둘 다 멈추는 전송을 고치지 못하며, 큰 전송이 멈추고 작은 전송이 성공한다면 패킷 크기와 MTU에 관심을 두어야 합니다.

연결은 되지만 내부 호스트 하나에 도달하지 못하는 클라이언트는 보통 라우팅, 방화벽 규칙, 빠진 반환 경로를 살펴봅니다.

관리형 서비스라면 서버 쪽이 이미 그것을 전제로 만들어져 있으므로 운영자의 프로파일이 지정한 인터페이스 구성을 사용하십시오. 자체 구축이라면 애플리케이션의 실제 요구에서 선택하고 그 이유를 선택 옆에 적으십시오.

문제는 어느 옵션이 더 강한가가 아닙니다. 트래픽이 실제로 어느 쪽을 필요로 하는가입니다.