한 호스트에서 TCP와 UDP로 OpenVPN 제공하기
2.7 이전에는 프로세스 하나가 전송 방식 하나만 바인딩합니다. 브리지된 TAP 쌍, 두 개의 TUN 서브넷, 공유 풀을 비교한 뒤 각 프로필을 해당 리스너에 맞추십시오.
TCP 443만 허용하는 네트워크는 UDP를 문제없이 통과시키는 네트워크와 공존하며, 서버 한 대가 둘 다를 처리해야 합니다. proto udp 이 있는 프로필은 두 번째 그룹에 응답하고 첫 번째 그룹에서는 실패하며, 같은 구성을 proto tcp 로 바꾸어도 두 번째 리스너가 생기지는 않습니다. 이 지시자는 프로세스 하나에 전송 방식 하나를 선택합니다. 나머지 모든 것은 그 제약에서 비롯됩니다.
프로세스를 여러 개 실행하거나, 여러 소켓을 동시에 바인딩할 수 있는 버전을 실행해야 합니다.
2.7 이전에는 프로세스 하나가 전송 방식 하나를 바인딩합니다
커뮤니티 OpenVPN은 proto 이 기술하는 소켓을 바인딩하며, 그 지시자는 인스턴스에 전송 방식 하나를 선택합니다. TCP와 UDP는 별도의 스택이므로 같은 포트 번호를 둘이 동시에 점유할 수 있지만, 프로세스 하나가 그럴 수는 없습니다. 그래서 2.6 계열은 데몬마다 전송 방식 하나를 제공합니다. OpenVPN 2.7은 서버에 대해 그 제한을 없앴고, 이제 서버는 프로세스 하나에서 여러 --local 문을 통해 여러 소켓을 바인딩할 수 있습니다.
어느 답을 기준으로 설계하든 2.7 구성은 자체 구성 문법을 가진 다른 운영 모델이므로 먼저 버전을 확인하십시오. 2.6용으로 쓰인 안내서는 그렇게 말하지 않아도 두 개의 프로세스를 전제합니다.
두 인스턴스를 실행하는 세 가지 방법
TAP 인터페이스에서는 전송 방식마다 인스턴스 하나를 실행하고 호스트에서 두 개의 tap 장치를 브리지합니다. 두 클라이언트 집합이 같은 브로드캐스트 도메인에 들어가므로 주소 풀 하나가 둘을 모두 덮을 수 있고 브로드캐스트에 의존하는 프로토콜도 계속 동작합니다. TUN에서는 브리징을 쓸 수 없으므로 가장 단순한 분리는 각 인스턴스에 자체 서브넷을 주고 라우팅이 두 클라이언트 집합을 분리하게 합니다. 세 번째 선택지는 각 인스턴스가 learn-address 스크립트를 호출해 해당 인스턴스의 장치를 통해 클라이언트에 /32 경로를 설치하도록 하여 풀 하나를 유지합니다.
이 세 번째 구성은 스크립트가 데이터 경로의 일부가 되어 추가, 갱신, 삭제 이벤트를 올바르게 처리해야 하므로 사람들이 자주 요청하면서도 가장 주의가 필요한 구성입니다.
| Arrangement | Interfaces | Address pool | Cost |
|---|---|---|---|
| Bridged TAP pair | Two tap devices joined by a bridge | One shared pool | Broadcast traffic and bridge maintenance |
| Two TUN subnets | Two tun devices, no bridge | One pool per instance | Routing rules and two plans |
| Shared pool with routes | Two tun devices plus a hook | One pool across both | A script on the data path |
두 인스턴스를 분리하십시오
각 인스턴스에는 별도의 포트나 주소, 별도의 상태 파일, 별도의 로그 대상도 필요합니다. 두 데몬이 하나의 상태 파일에 덧붙이면 장애 때 읽을 수 없는 출력이 생기는데, 바로 그때 그 출력이 필요합니다. 두 번째 인스턴스가 특정 주소를 바인딩한다면 그 주소는 프로세스가 시작할 때 호스트에 존재해야 하며, 그렇지 않으면 키에 대해 아무 말도 하기 전에 바인딩 실패로 종료됩니다.
유닛과 프로필 이름만 봐도 전송 방식이 드러나게 이름을 붙이십시오. 다음 운영자가 어느 쪽이 TCP인지 알기 위해 구성을 열어야 해서는 안 됩니다.
프로필을 리스너에 맞추십시오
proto tcp 을 실행하는 서버는 proto tcp-client 이 있는 클라이언트 프로필을 기대하며, proto udp 을 그대로 가진 프로필은 그 리스너에 대해 사용자가 조치할 수 있는 오류도 없이 시간 초과됩니다. 배포가 두 전송 방식을 모두 제공한다면 프로필을 두 개 두고, 지원 담당자가 어느 것을 시도했는지 알 수 있게 표시하십시오. 포트 번호만으로는 전송 방식을 설명하지 못합니다.
방화벽 규칙도 같은 구분을 따르며, UDP 1194 규칙은 TCP 1194에 대해 아무것도 말하지 않고, 한 주소에 대한 규칙이 다른 리스너를 덮지도 않습니다.
먼저 서버의 시각을 읽으십시오
서버에서 ss -lntup 로 시작해 TCP와 UDP 리스너가 모두 나타나는지 확인하십시오. 그다음 각 종류의 클라이언트를 하나씩 연결하고 서로 다른 주소를 가진 두 항목이 상태 출력에 있는지 확인하십시오. 소켓은 있는데 클라이언트가 오지 않는다면 데몬이 패킷을 보기 전에 경로나 방화벽이 이를 거부하는 것입니다.
절대 나타나지 않는 소켓은 구성이나 바인딩 문제이고, 나타나지만 연결을 기록하지 않는 소켓은 필터링 문제입니다. 클라이언트 입장에서는 둘이 똑같아 보이므로 서버 자체의 시각을 먼저 봅니다. TCP는 헤드 오브 라인 블로킹을 동반하므로 이를 제공하는 것은 UDP 경로가 깨끗한 클라이언트에게 업그레이드가 아니라 도달성 대책입니다.