10P by neo 1일전 | ★ favorite | 댓글 4개
  • 네트워크 인프라는 스위치, 브리지, 라우터, 로드 밸런서, 방화벽 등으로 구성됨
  • 운영체제는 패킷을 분류하고, 큐에 배치하며, 방화벽 규칙을 적용하는 등 네트워크 통신을 제어함
  • 그렇다면 존재하지 않는 전송 계층 프로토콜을 사용하면 어떻게 될까?
  • OS가 허용할까? 패킷이 실제로 전달될까? 방화벽이 차단할까?
  • 직접 실험을 진행하여 확인함

인터넷 프로토콜 개요

  • 인터넷은 여러 계층의 프로토콜이 데이터를 전달하는 방식으로 동작함
  • 애플리케이션이 요청을 보내면, OS가 이를 여러 네트워크 계층의 헤더로 감싸면서 전송함
  • 전송 계층(Transport Layer): TCP(6), UDP(17) 등의 프로토콜이 위치함
  • IP 헤더의 Protocol 필드를 수정하여 미사용된 번호를 넣으면 어떤 일이 벌어질까?

실험 #1: 내 PC에서 직접 테스트

실험 방법

  1. HDP(가짜 프로토콜) 정의: 기존 프로토콜과 전혀 다른 새로운 전송 계층 프로토콜 설계
  2. 서버와 클라이언트 구현: 패킷을 송수신하는 프로그램 개발
  3. 루프백(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: 인터넷에서 패킷 전송

실험 계획

  1. DigitalOcean VPS 설정: 독일 프랑크푸르트에 있는 클라우드 서버에 실험 환경 구축
  2. HDP 패킷 전송: 내 PC(사우디아라비아)에서 DigitalOcean 서버로 패킷을 송신
  3. 네트워크 장비의 반응 분석: 패킷이 도착하는지, 방화벽이 차단하는지 확인

예상 결과

  • 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() 동작 방식이 제각각임
  • 방화벽과 NAT 장비가 비표준 프로토콜을 차단함
    • 개인 네트워크에서는 동작하더라도 인터넷에서는 거의 불가능함
  • 성능 개선 효과 없음
    • UDP 기반으로 구현된 QUIC 등 이미 검증된 대안이 존재함
  • TCP/UDP를 사용하자
    • 표준 프로토콜을 사용하면 포트 기반 NAT, 방화벽, 라우팅 등이 자동으로 지원됨

추가 자료

옛날 스타크래프트에서 하마치로 멀티를 할 때 IPX가 있었는데, 그 때 이게 뭘까 참 궁금했던 기억이 나네요.

생각해보니 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 이전에 유사한 작업을 수행했음