GN⁺: TCP나 UDP를 사용하지 않으면 무슨 일이 일어날까?
(github.com/Hawzen)- 네트워크 인프라는 스위치, 브리지, 라우터, 로드 밸런서, 방화벽 등으로 구성됨
- 운영체제는 패킷을 분류하고, 큐에 배치하며, 방화벽 규칙을 적용하는 등 네트워크 통신을 제어함
- 그렇다면 존재하지 않는 전송 계층 프로토콜을 사용하면 어떻게 될까?
- OS가 허용할까? 패킷이 실제로 전달될까? 방화벽이 차단할까?
- 직접 실험을 진행하여 확인함
인터넷 프로토콜 개요
- 인터넷은 여러 계층의 프로토콜이 데이터를 전달하는 방식으로 동작함
- 애플리케이션이 요청을 보내면, OS가 이를 여러 네트워크 계층의 헤더로 감싸면서 전송함
- 전송 계층(Transport Layer): TCP(6), UDP(17) 등의 프로토콜이 위치함
- IP 헤더의
Protocol
필드를 수정하여 미사용된 번호를 넣으면 어떤 일이 벌어질까?
실험 #1: 내 PC에서 직접 테스트
실험 방법
- HDP(가짜 프로토콜) 정의: 기존 프로토콜과 전혀 다른 새로운 전송 계층 프로토콜 설계
- 서버와 클라이언트 구현: 패킷을 송수신하는 프로그램 개발
- 루프백(loopback) 테스트: OS가 자체적으로 패킷을 처리하는 방식 관찰
실행 과정
$ sudo cargo run --bin server # 서버 실행
$ fortune | cowsay | sudo cargo run --bin client 127.0.0.1 # 클라이언트 실행
결과
- OS가 HDP 패킷을 정상적으로 처리하여 루프백 인터페이스를 통해 다시 수신됨
- IP 프로토콜 번호를 변경하여 추가 테스트 진행
- 1 (ICMP), 2 (IGMP), 6 (TCP) → 서버에서 감지되지 않음
- 50, 51 (IPSec 관련 프로토콜) → 클라이언트에서 전송 자체가 차단됨
-
256 (IP 프로토콜 번호 범위 초과) →
socket()
호출 단계에서 오류 발생
원인 분석
- OS가 특정 프로토콜 번호를 시스템적으로 예약하여 차단하는 경우 존재
- Darwin(BSD 기반 macOS)에서는
socket()
호출 시 protocol=0을 설정하면 일부 패킷이 자동 필터링됨 - IPSec 관련 프로토콜은 보안상의 이유로 차단될 가능성이 큼
- IPv4 프로토콜 번호는 8비트이므로 0~255까지만 유효함
실험 #2: 인터넷에서 패킷 전송
실험 계획
- DigitalOcean VPS 설정: 독일 프랑크푸르트에 있는 클라우드 서버에 실험 환경 구축
- HDP 패킷 전송: 내 PC(사우디아라비아)에서 DigitalOcean 서버로 패킷을 송신
- 네트워크 장비의 반응 분석: 패킷이 도착하는지, 방화벽이 차단하는지 확인
예상 결과
- HDP 패킷이 정상적으로 전달되거나, 일부 ISP 또는 DigitalOcean의 방화벽이 차단할 가능성이 있음
실제 결과
- 첫 번째 패킷만 전달되고 이후 패킷은 차단됨
-
tcpdump
를 사용하여 확인한 결과:- 내 PC에서 패킷이 정상적으로 전송됨
- DigitalOcean 서버에서는 첫 번째 패킷만 감지됨
- 이후 패킷은 어딘가에서 차단됨 (NAT, 방화벽, ISP 등)
원인 분석
- DigitalOcean에서는 비표준 IP 프로토콜을 지원하지 않음
- 클라우드 제공업체의 방화벽 정책이 주요 원인일 가능성이 큼
- 왜 첫 번째 패킷만 도착했는지는 불명확함
AWS에서 재실험
- AWS에서 두 대의 인스턴스를 사용하여 실험을 재진행함
- 같은 데이터센터 내에서는 HDP 패킷이 정상적으로 송수신됨
- 그러나 인터넷을 통해 전송할 경우 DigitalOcean과 동일한 첫 번째 패킷만 도착하는 문제 발생
주요 이슈
- NAT(Network Address Translation): TCP/UDP 포트 기반으로 작동하므로 HDP 같은 신규 프로토콜을 다룰 방법이 없음
- 방화벽/네트워크 필터링: 대부분의 ISP와 클라우드 제공업체는 미승인 IP 프로토콜을 차단함
- 네트워크 장비의 최적화 문제: 일부 네트워크 장비는 비표준 패킷을 무조건 삭제할 가능성이 있음
결론: TCP와 UDP를 사용하는 것이 최선
-
OS 간의 네트워크 스택 구현이 다름
- Linux, macOS, Windows에서의
socket()
동작 방식이 제각각임
- Linux, macOS, Windows에서의
-
방화벽과 NAT 장비가 비표준 프로토콜을 차단함
- 개인 네트워크에서는 동작하더라도 인터넷에서는 거의 불가능함
-
성능 개선 효과 없음
- UDP 기반으로 구현된 QUIC 등 이미 검증된 대안이 존재함
-
TCP/UDP를 사용하자
- 표준 프로토콜을 사용하면 포트 기반 NAT, 방화벽, 라우팅 등이 자동으로 지원됨
추가 자료
생각해보니 NAT이 모든걸 막겠군요...IPv6가 완전히 정착하고 NAT이 없어진다면(그럴 일은 없을 것 같지만) 자신이 만든 프로토콜로 통신하는것도 가능할 수 있겠어요.
오호 좋은 시도군요...
네트워크 근간을 흔드는 시도는 좋았으나, 이 세상의 모든 네트워크 장비는 TCP/UDT 에 특화된 장비만 있어서...
네트워크 장비가 틀 찍어내기라는 것을 모를때... 는 가능할꺼같은데... 알고나면 내가 잘되서 내 프로토콜을 모두가 사용하도록 하겠다가 아니면 못하는 거란걸 알게되죠...
Hacker News 의견
- TCP보다 우수하지만 채택되지 않은 오래된 프로토콜인 SCTP가 있음
- 네트워크 하드웨어가 TCP와 UDP 외의 모든 것을 차단했기 때문임
- 다양한 전송 프로토콜을 구현한 사람으로서 IP 위에 계층을 쌓는 가장 큰 장애물은 WAN 라우터가 아닌 소비자 NAT 장치임
- 특정 Netgear 라우터의 경우, 트래픽이 끝까지 살아남지만 첫 4바이트가 0으로 변하는 특정한 손상이 발생했음
- 이는 TCP/UDP로 처리되었지만 실제 번역 경로는 따르지 않았다고 의심됨
- TCP나 UDP를 사용하지 않으면 통신이 어려울 것임
- 인터넷은 TCP와 UDP를 표준으로 삼고 있음
- 다른 프로토콜을 처리할 수 없는 장치가 많음
- 인터넷 하드웨어를 모두 교체하는 것은 IPv4를 폐기하는 것보다 더 오래 걸릴 것임
- 새로운 프로토콜의 큰 이점이 있어야만 모든 기업과 정부가 큰 비용을 들여 지원을 구현할 것임
- 기사의 끝이 클리프행어처럼 느껴짐
- 왜 커스텀 프로토콜의 단일 패킷만 통과하고 나머지는 드롭되었는지 궁금함
- TCP/UDP 패킷은 OS 네트워크 스택에 의해 특정 포트를 듣는 프로세스에만 전송된다고 생각했음
- 이는 보안 기능일 수 있으며, 권한이 없는 프로세스는 일부 포트를 들을 수 없음
- 다른 프로세스가 모든 트래픽을 캡처할 수 있을 것이라고 기대하지 않음
- 여러 전송 계층 프로토콜의 트래픽을 캡처할 수 있는지 몰랐음
- 아마도 해당 시스템 호출은 높은 권한을 요구할 것임
- 인터넷 프로토콜과 라우팅 장비가 오늘날 처음부터 설계되었다면 어떻게 되었을지 궁금함
- 훨씬 큰 패킷과 UDP 스타일의 기본 프로토콜이 HTTP를 대체했을 것임
- 간단한 스트리밍 프로토콜이 TCP를 대체하고 비디오 재생을 지원했을 것임
- 이 두 프로토콜이 대부분의 트래픽을 더 효율적으로 처리했을 것임
- "바퀴를 재발명한다면 어떻게 될까?"라는 가정임
- 패킷 소켓이 필요함
- IP 네트워크는 모든 것을 전달해야 하지만 NAT가 주요 문제임
- IPv6로 시도해보는 것이 흥미로울 것임
- TCP/UDP/IP가 모든 것을 장악하기 전의 다른 프로토콜을 사용했을 것임
- 모두 UUCP를 사용했을 것임
- TCP/UDP 이전에 유사한 작업을 수행했음