TCP 443은 정말 도움이 될까? 서버가 그곳에서 수신할 때만 그렇다
TCP 프로필은 대체 수단이지 위장이 아니다. 서버가 해당 포트에서 수신하는지 확인한 다음, 이중 TCP 비용과 연결 불가를 저울질하라.
TCP 443은 전제 조건이 있는 대체 수단이지, 어떤 필터든 통과시키는 위장이 아니다. 운영자가 이미 그 포트에서 TCP 수신기를 공개했고 경로가 몇 시간씩 열린 연결을 견딜 때 도움이 된다. 둘 중 하나가 없으면 보통 시간 초과로 실패하며, 시간 초과는 어느 쪽이 없었는지 거의 알려 주지 않는다. 전환 여부를 결정하려면 세 가지 질문이 필요하고, 그중 포트 번호에 관한 것은 하나뿐이다.
포트 번호는 전송의 약속이 아니다
포트는 끝점에 이름을 붙이고, TCP는 그것을 순서가 있는 바이트 스트림으로 바꾸며, OpenVPN이 그 스트림 안에서 무엇이 흐르는지 결정한다. 같은 번호의 웹 서버는 전혀 다른 애플리케이션 구성을 쓰므로, 443 포트를 공유한다고 해서 필터에게 둘이 비슷해 보일 뿐 그 이상은 아니다. 번호는 필터가 읽는 단서이지 패킷의 내용을 바꾸는 속성이 아니다. 포트를 공유한다는 이유로 둘을 같다고 보는 것이 여기서 생기는 혼란 대부분의 배경이다.
중간 장치는 포트에 대해 단순한 허용-또는-차단 결정을 거의 내리지 않는다. 많은 장치가 첫 바이트들을 검사하고, 일부는 목적지를 고정하며, 일부는 너무 오래 열린 연결을 재설정한다. 그래서 같은 프로필이 한 네트워크에서는 되고 다른 네트워크에서는 시간 초과가 나므로, 대체 수단은 약속으로 민기보다 지원되는 옵션으로 시험해 볼 가치가 있다. 필터가 트래픽을 들여다보 때 포트 번호는 그저 가장 먼저 보는 항목일 뿐이다.
프로필을 건드리기 전에 수신기를 확인하라
서버는 그 포트에서 TCP로 설정되어 있어야 하고, 클라이언트 프로필은 같은 전송을 요청해야 한다. UDP 프로필을 고쳐 TCP를 요청해도 수신기는 생기지 않으며, 그 결과 나타나는 시간 초과는 포트를 버리는 방화벽과 구별되지 않는다. 일부 서비스는 전송마다 별도의 끝점과 ID 설정을 공개하므로, 운영자의 자체 TCP 프로필이 있으면 내려받아라. 손으로 편집하는 것은 통제된 시험에는 좋지만 제공자가 의도한 구성을 짐작하는 방법으로는 나쁘다.
그 일치의 양쪽은 구성에 나타나며, OpenVPN 프로젝트의 링크 옵션이 두 형태를 모두 문서화한다. 최소한의 짝은 이렇게 생겼다:
# server: accept TCP on this port
proto tcp-server
port 443
# client: request the same transport
proto tcp
remote vpn.example.com 443세 가지 조건이 대체 수단의 값을 결정한다
첫째 조건은 운영자가 그 전송을 아예 제공하는 것인데, 그것이 없으면 나머지는 중요하지 않다. 둘째는 경로가 장시간 세션을 살려 두는 것인데, 일부 네트워크는 포트를 아예 막는 대신 열린 연결을 재설정한다. 셋째는 대체 수단이 의도된 예외인지, 아니면 고치지 않은 결함을 숨기는 임시방편인지다.
각 조건에는 값싼 점검이 있다. 어느 하나에서 실패하면 클라이언트 쪽에서는 똑같이 보인다:
| Condition | How to check it | What a failure decides |
|---|---|---|
| The server offers TCP | The operator's profile list, or a listening-socket check on the server | No client-side edit can help |
| The path keeps long sessions | A test connection left open for an hour | Reconnects will look like server faults |
| The fallback is deliberate | A change record naming the UDP fault | The underlying fault stays invisible |
전송을 비교하기 전에 캡티브 포털의 로그인을 마쳐라. 기기를 허용하지 않은 네트워크는 두 전송을 모두 막으므로, 그때의 비교는 터널이 아니라 포털을 재는 것이다. 로그인하고, 일반 브라우징이 되는지 확인한 다음에야 시험을 시작하라.
당신이 받아들이는 비용: TCP 속의 TCP
TCP는 손실된 세그먼트를 다시 보내고 그 순서를 유지한다. TCP를 쓰는 애플리케이션이 TCP 터널 안에서 돌면 두 복구 계층이 같은 손실에 반응하며, 바로 그 상호작용이 손실이 있는 경로에서 터널을 느리게 느껴지게 한다. 증상은 깔끔한 실패가 아니라 지연과 흔들림이며, 그래서 먼 쪽을 탓하기 쉽다. 결론을 내리기 전에 클라이언트에서 두 전송 모두로 측정하라.
UDP는 이 중첩을 피하며, 이것이 운영자들이 그것을 선호하고 TCP는 대안으로만 제공하는 주된 이유다. 안정적인 TCP 연결은 여전히 도달할 수 없는 UDP 연결보다 유용하므로, 비교는 좋은 선택과 나쁜 선택 사이가 아니라 두 가지 실제 비용 사이에서 이루어진다. 비교하는 동안 기기와 접속망을 그대로 두어라, 그렇지 않으면 결과는 잘못된 변수를 설명하게 된다.
일부 클라이언트 기능은 한 전송에서만 문서화되어 있어, 대체 프로필이 의존하던 동작을 조용히 빼버릴 수 있다. TCP 프로필을 단순한 교체로 보기 전에 그 옵션의 전송 요구 사항을 읽어라.
다른 전송이 건드리지 않는 결함
만료된 인증서에는 여전히 시계 확인이나 갱신이 필요하고, 거부된 계정에는 여전히 올바른 자격 증명이 필요하다. 익숙한 포트 번호는 누구도 인증하지 않으므로, 운영자가 준 서버 ID 확인은 그대로 두어라. 응답하는 포트는 무언가가 수신 중이라는 것만 말한다.
터널이 올라오는데도 목적지가 계속 실패한다면, 남은 문제는 연결 후의 라우팅이나 이름 해석이지 전송이 아니다. 포트를 돌며 오후를 보내는 대신 그 경로를 따라가라. 프로필은 어떤 전송을 시도할지 알려 주지만, UDP 경로가 왜 실패했는지는 결코 알려 주지 않는다.