OpenVPN은 집에서는 연결되지만 한 네트워크에서는 안 된다: UDP인가 TCP인가?

같은 프로필이 집에서는 연결되지만 호텔, 캠퍼스, 지사 네트워크에서는 멈춘다. 자격 증명은 바뀌지 않았으므로 흥미로운 변수는 경로다. OpenVPN이 패킷을 읽기 전에 무슨 일이 일어나는가. 시험할 수 있는 순서대로 네 가지 후보 원인을 비교하는 것이 인증서를 추측하는 것보다 낫다. 각각 다른 흔적을 남기고, 그 흔적이 원인을 구분한다.

어느 단계에서 실패했는지가 어떤 비교가 중요한지를 알려준다

클라이언트 로그에는 이미 어디까지 진행했는지가 기록된다. TLS 키 협상이 시간 제한 내에 발생하지 않았다는 줄은 첫 패킷이 나갔지만 쓸 만한 응답이 돌아오지 않았다는 뜻이며, 이는 경로를 가리킨다. 인증서 거부는 전혀 다르게 보인다. 응답이 도착하고, 그다음 특정 검증 오류가 이유를 밝힌다. 재시도 루프 직전의 마지막 줄을 적어 두라. 네트워크 간에 비교할 값이 바로 그것이다.

나중이 아니라 재시도하는 동안 캡처하라. 클라이언트에서 tcpdump -ni any udp port 1194는 응답이 아예 돌아오는지를 보여 준다. 직접 관리하는 서버의 WAN 인터페이스에서 반복하면 그 패킷이 정말 반대편에 도달하는지 드러난다.

단방향 트래픽은 여기서 얻을 수 있는 가장 유용한 결과다. 간헐적인 불만을 조사할 방향으로 바꿔 주기 때문이다. 캡처 파일을 보관하라. 같은 문제의 다음 보고는 설명보다 증거로 닫는 편이 쉽다.

UDP 필터링과 닫힌 포트

많은 액세스 네트워크는 지속적인 UDP를 수상하게 여기고, 일부 ISP도 동의한다. 닫힌 포트는 클라이언트 쪽에서 같은 침묵을 만든다. 차이는 선택성이다. 필터는 어떤 목적지나 포트를 버릴지 까다롭게 굴고, 닫힌 포트는 그 포트로 향하는 모든 것을 거부한다.

443 포트의 TCP 프로필이 흔한 우회책이다. 평범한 HTTPS 흐름과 비슷해 대부분의 캡티브 포털과 송신 필터를 통과한다. 두 가지 조건이 성립해야 한다. 서버는 proto tcp-server로 수신해야 하고 클라이언트는 proto tcp-client로 일치해야 하며, 운영자가 그 대체 엔드포인트를 공개해야 한다. 잘 되던 UDP 프로필을 TCP 443이라고 고쳐 써도 반대편에 아무것도 수신하지 않으면 아무 소용이 없다.

닫힌 포트는 검열 문제가 아니라 구성 문제다. 가정용 라우터 뒤에 있는 서버는 UDP 포트를 포워딩해야 하고, 라우터 방화벽이 이를 허용해야 한다. 포트가 한 번도 허용되지 않았다면 자격 증명과 무관하게 모든 클라이언트가 협상에서 실패하고, 실패는 네트워크가 아니라 서버를 따라간다.

오래된 프로토콜은 이 축에서 비교가 나쁘다. PPTP는 TCP 1723과 GRE가 필요하고, GRE는 포트가 아니라 IP 프로토콜 47이므로 일반적인 포트 포워딩으로는 표현할 수 없다.

스위치가 패킷을 버리는 경우

관리형 스위치는 의도적으로 터널을 버릴 수 있다. 일부 HPE 및 Aruba 모델은 고급 보안 섹션에 UDP 플러드 보호 제어를 제공하며, 때로 Prevent UDP Blat Attack이라고 표시된다. 그 제어가 활성화되면 스위치 뒤의 서버는 아무것에도 응답하지 않고 모든 클라이언트가 같은 방식으로 시간 초과된다. 이를 해제하고 실행 중인 구성을 저장하는 것이 전부의 수리이지만, 스위치가 실제로 경로에 있다는 것을 확인한 뒤에만 그렇다.

스위치의 버림과 공급자 차단을 구분하는 것은 반대 증거다. ISP에 티켓을 열기 전에 인터페이스 카운터와 플러드 보호 로그를 읽어라. DoS나 플러드 보호가 있는 소비자 라우터도 같은 형태로 실패하고, UDP 유휴 시간 제한이 짧은 모든 미들박스도 마찬가지다. 끝나지 않는 핸드셰이크는 버림을 시사하고, 몇 분의 정적 후 죽는 터널은 시간 제한을 시사한다.

프로필을 바꾸기 전에 클라이언트와 서버 사이의 모든 장치를 적어라. 잘못된 계층에 적용한 수정은 다음 네트워크까지는 옳아 보인다. 그 목록은 다음 엔지니어에게 전체 조사를 반복하지 않고 어디를 봐야 하는지도 알려 준다.

DNS 실패처럼 보이는 주소 겹침

10.0.0.0/8 안에서 번호가 매겨진 액세스 네트워크는 터널 풀과 겹칠 수 있고, 리졸버는 보통 그 풀 안에 있다. 노트북이 Wi-Fi에서 10.184.178.50 같은 주소를 /8 마스크로 받으면 모든 10.x 목적지는 정의상 로컬이다. 10.4.0.1로 가는 패킷은 그러면 LAN으로 가고, 터널은 살아 있으며, 이름 해석은 실패한다.

ip addr는 겹침을 한눈에 드러내고, ip route get 10.4.0.1은 패킷이 실제로 어디로 전달될지 보여 준다. 보이는 증상이 리졸버 실패이기 때문에 이것은 여러 차례의 DNS 변경을 견디는 경우가 많다.

풀의 번호를 다시 매기거나 그 액세스 네트워크를 범위 밖에 두어라. 어떤 클라이언트 측 설정도 겹침에서 복구하지 못한다.

TCP 대체 경로와 경로 수정 중 선택

경로를 통제할 수 없고 사용자가 오늘 당장 일해야 한다면 TCP 대체 경로를 택하고 그 비용을 받아들여라. TCP 안의 TCP는 손실이 있는 링크에서 나쁘게 동작하고, 대체 경로에는 당신이 운영하는 리스너가 필요하다. 차단이 자신이 소유한 인프라에 있다면 경로 수정을 택하라. 방화벽 규칙이 두 번째 리스너보다 저렴하다. 어느 쪽이든 계층을 순서대로 훑어라. 링크, 외부 전송, 협상, 내부 라우팅. 그 네트워크에서 실패한 단계만이 중요한 사실이다.

결과를 사용자별이 아니라 네트워크별로 기록하라. 그러면 같은 실패의 다음 보고는 인증서 이론이 아니라 알려진 단계에서 시작한다. 그 기록은 필요할 경우 영구적인 두 번째 리스너를 정당화하는 근거도 된다.