전체 과정

이 글에서는 Oracle Cloud와 Vultr에서 Bring your own IP 를 사용하는 방법을 다룬다. 궁극적으로, 몇개의 글에 걸쳐 BYOIP가 잘 작동하는지와 Anycast가 예상대로 진행되는지를 다룰 것이다. 전체적인 과정 자체는 AWS, GCP에서도 유사 할 것이다.

Bring Your Own IP를 사용하기 위한 과정은 크게 다음과 같다.

1. IPXO 가입 및 인증
2. IP블록 구매
3. ASN 등록 및 LOA 발급
   * 우리가 ASN을 발급받을 필요는 없다! 우리는 Vultr, Oracle 측의 ASN에 올라탈것이다.
4. RPKI 등록 인증
5. 호스팅 업체의 BYOIP 풀에 등록

---

BYOIP를 사용하기 위한 비용은 다음과 같이 쓰였다. (업체 및 IP 블록의 시세에 따라 달라질 수 있다):

• 월간 IP 임대료 (100$) + 4% 수수료 (Paypal 기준) = 104$
• 1회성 ASN 등록 비용: 9$ + 4% 수수료 (Paypal 기준) = 9.36$
• BGP 담당 가상 머신: 5$ (리전당 비용)
  • Vultr은 BGP 전파를 위하여 VM에다가 Bird 라는 BGP Daemon을 실행해야 한다.
  • 기존에 짬뽕으로 사용하는 서버가 있다면 필요 없지만, 짬뽕 서버가 없다면 서버를 추가 해야 한다.
  • Anycast를 사용하려면 리전(한국, 일본, 미국···) 마다 BGP 데몬이 필요하므로, 리전별로 비용이 추가된다.

결과적으로 월 114$, 1회 10$ 정도가 쓰였다. (/24, Vultr 기준으로 2개 region 사용시)

필자는 100대에 달하는 VM을 관리하고 있다. 그러나, 해당 VM들은 Oracle Cloud의 임시 IP (Ephemeral Public IP)를 발급받아 사용한다. 임시 IP는 VM을 재생성 할 때 마다 회수된다. 또한, IP 주소가 서로 멀다. 그러므로 관리상의 불편함이 발생했다.

또한, 이렇게 발급한 서버는 특정 리전에서만 사용할 수 있다. 만약 DDos가 발생하거나 호스팅사에 장애가 발생하면 그대로 먹통이 된다. 이 문제를 해결하기 위해서 Anycast를 적용해서 장애가 발생하더라도, 특정 지역에서만의 문제로 격리시키려 한다.

IP 블록 임대 (IP lease)

이 글에서는 /24 와 같은 CIDR 표기법을 사용한다. 아래에서 계속 나올 /24는 256개의 IP 주소 (1.2.3.***)을 의미한다. /32는 IP 1개를 의미한다.

일단 어째됐든간에 IP 블록을 가져야 한다. IP 블록을 구매 하려면 비용도 /24(256개 IP)에 1억원 가까이 들어가고, 준비해야 할 것도 많다. 그러므로, 필자는 IP 임대를 선택했다. IP대여는 /24에 월 10만원에서 20만원선으로 가격이 형성되어 있다. (2024-08-31 기준)

IP를 대여해 주는 서비스는 상당히 적다. 그나마 믿음이 가는 곳은 IPXO이다. 필자도 IPXO를 선택했다. 허리케인 네트워크(he)에서 검색 결과가 가장 많이 나온것으로 보아, 가장 믿음직스러웠다.

(통큰*이, iw**v와 같은) 국내 호스팅사에서는 “국내 트래픽”과 “해외 트래픽”을 나눈다. 국내 트래픽은 네트워크 품질 SLA 대상이지만, 해외 트래픽은 그렇지 않다. 패킷 드롭이 생각보다 많이 발생한다.

해당 업체들에게 문의 했을때 국내·국외 트래픽 기준은 실제 서버 소재지가 아니라, KRNIC에서 할당한 IP인지 여부를 가지고 판단한다고 한다. (https://한국인터넷정보센터.한국/jsp/statboard/IPAS/inter/sec/currentV4Addr.jsp)

국내의 호스팅 서버에서 자주 접속할 예정이라면 KRNIC에서 부여한 IP를 빌리는 것이 좋아 보인다. 국내는 위의 ipxo와 같은 서비스는 없고, 대신 https://www.toyocs.net/ip-lease/ 와 같이 남는 IP 자산을 임대해 주는 서비스만 있는것으로 보인다.

IPXO 가입

IPXO를 사용하기 위해서는 사용자·업체 인증을 받아야 한다. 특히 부여된 IP로 메일링 시스템과 같은 이상한 서비스를 하는지가 주 관심사로 보인다. (대여받은 IP로 깽판치면 원래 소유주나 다음 사용자나 피해를 받을 수 있다는 점에서 합리적으로 보인다)

회원가입 이후, 회사를 등록해야 한다. 그리고 해당 페이지에서 규제 관련 정보를 입력해야 한다. 또한, abuse email 주소로 사업자 등록증이 있는지, IP 블록은 무엇을 위해 쓸 것인지 물어본다. 특히, 메일링 서비스가 있는지 물어본다. (절대 IP를 이상한 짓에 사용하진 말자.)

회사 인증을 받기 전 까지는 IP 블록의 가격을 볼 수만 있다. 회사 인증까지 완료되면 비로서 IP를 구매할 수 있다.

IP 블록의 RIR (대륙별 인터넷 등록체) 선택

대륙별로 IP 자원을 관리하는 기구가 있다. 이것을 RIR^{Regional Internet Registries}이라고 한다. 전 세계의 IP는 각 RIR에 분배된다. RIR에서 다시 국가·기관별 네트워크 관리체에게 IP를 부여해 준다. 그러므로, IP 주소의 최상위 관리 기관은 RIR이다.

우리가 컴퓨터에 사용하는 IP는 APNIC (아시아·태평양 네트워크 정보센터)에 부여된 IP중 일부이다. APNIC에서는 다시 KRNIC (한국 네트워크 정보센터)에 IP 주소를 할당해 준다. 이후 KRNIC에서 KT, SKT, LGT 와 같은 사업자에게 IP 블록을 뿌려준다.
아무튼, IP 블록의 최상위 관리 기관은 RIR이라는 점을 알면 된다.

BYOIP를 지원하는 호스팅 업체에서는 해당 RIR에 이걸 써도 되는 IP인지를 검사 한다. (후술할 ROA) 이때, 호스팅 업체 마다 지원하는 RIR이 다를 수 있다. 예를 들어, Oracle Cloud는 ARIN, RIPE, APNIC 세 곳 만을 지원한다. AWS도 똑같이 3곳의 RIR만 지원한다. 호스팅 업체의 문서를 확인하여, 지원하는 RIR 목록을 먼저 확인 해야 한다.

AFRINIC(아프리카 지역), LACNIC (라틴 지역)의 IP 블록을 대여 받았다면 Oracle Cloud, AWS의 BYOIP에 IP 등록이 불가 할 수 있다.
반드시 호스팅 업체마다 사용 가능한 RIR을 확인하자.

IPXO에는 RIR를 필터링 할 수 있는 패널이 대문짝 하게 있다. 그러므로, 호스팅 업체의 요구조건만 확인하면 될 것이다. 참고로, KRNIC는 APNIC 아래에 있다. 그러므로 KRNIC에서 부여한 IP (한국 IP) 블록이 되는지는 APNIC의 IP 블록을 지원하는지 확인하면 된다.

IP 구매 후 ASN 등록

우리가 ASN을 발급 받을 필요는 없다. 주변에 이야기를 해보니 ASN을 만들어야 하지 않냐는 말이 있었다. 정답은 “그렇지 않다” 이다.

ASN은 백본 네트워크를 만들고, 직접 BGP를 뿌리는 주체가 될 때 필요하다. 왠만한 경우, 우리는 Oracle Cloud나 Vultr의 백본망을 사용할 것이다. 또한 Oracle Cloud와 Vultr에서 BGP 전파를 할 것이다.
이 경우, BGP를 뿌리는 주체인 Oracle Cloud와 Vultr의 ASN를 사용한다. 우리가 ASN을 따로 발급 받을 필요는 없다.

ASN 발급 비용만 해도 상당하다. KRNIC 기준 1회 300만원에, 연간 30만원을 납부 해야 한다. 또한, 망 구성도 등등을 다 제출해야 한다. ASN 등록은 잘못된 방향으로 가고 있을 가능성이 높으니, 다시 한번 확인해서 진행하자.

IP Block을 구매했다면 ASN을 연결해야 한다. 이 IP는 이 ASN에서 사용할 예정이다~ 라고 알려주는것과 같다. 엄밀하게 하자면 IP Block에 ASN을 등록하는게 아니다. 대신 ASN을 가진 업체가 BGP를 이용해서 “이 IP Block 패킷은 나한테 오게 하라” 라고 주변에 알려야 한다.

BGP는 주변 네트워크 장치에 “이 IP 블록”은 내 쪽으로 라우팅 되게 하라~ 라는 정보를 주는 시스템(프로토콜) 이다.

하지만, 문제는 BGP 자체는 인증 수단이 없다. 예를 들어서, IP 블록을 빌리지도 않았는데 “이거 내가 빌린거임 ㅇㅇ, 빨리 등록해 주셈” 하면 문제가 생길 수 있다. (BGP 하이제킹 등등) 나한테 패킷이 오지 않고, 이상한 망으로 패킷이 갈 수 있기 때문이다. 그래서, 각 업체들은 LOA와 ROA를 요구한다.

LOA^{Letter Of Authorization}는 인증 서류를 의미한다. 사업자 등록증이나 영업 허가서와 비슷하다. 이것을 해당 업체에 제출해서 서류상으로 사용권 검증 및 해당 ASN에 연결할 것을 확인한다.

ROA^{Route Origin Authorization}는 시스템 검증 수단이다. RPKI라는 인증서가 개입한다. 쉽게 이야기 해서, “이 IP는 이 ASN에 연결합니다” 라는 정보를 공인 인증서로 서명한다. 이렇게 생성한 데이터 및 인증정보를 ROA라고 한다. 이렇게 만든 ROA를 RIR에 올려야 한다. 호스팅 업체는 RIR에 ROA 정보가 제대로 있을 경우에만 IP 가져오기를 해 준다.

결국, LOA로 IP Block의 서류상 소유권을 인증하고, RPKI 시스템 상에서 ROA로 IP 블록에 대한 ASN 연결을 공고해야 한다.

LOA는 IPOX가 시스템적으로 작성해 준다. 그러나 ROA는 IP 실 소유주가 공인 인증서를 사용해서 처리해 해줘야 하는 작업이다. 그러므로 이것은 시스템적으로 할 수 없다. 또한, 수동으로 작업을 하다 보니 9$의 수수료가 발생한다. 수수료는 등록할 ASN의 갯수마다 발생한다. 즉, 2개의 ASN을 (Vultr, Oracle Cloud) 등록한다면 18$가 발생한다. (1회성이긴 한데, 숨어있는 비용이다)

Vultr의 ASN은 20473이다. BGP 등록 예시 페이지에 있는 AS64515는 내부 전용이므로 사용하면 수수료만 발생하고, 실질적인 라우팅이 되지는 않는다.
(필자도 처음에 내부용 ASN을 적었다. 다행히 IPXO 시스템이 경고를 줘서 알아챘다.)

Vutlr 문서의 Public ASN 부분을 확인하자.

LOA와 ROA를 위하여 IPOX에 ASN를 등록해야 한다. LOA는 바로 발급 되는데, ROA 처리는 다소 시간이 걸릴 수 있다. 필자의 경우에는 금요일 밤에 신청해서 일요일 오후에 처리 됐다. ROA 처리 과정은 이메일로 알려준다. 혹시나 등록됐는지가 궁금하다면 RPKI 상태 조회 페이지를 사용하자. IP CIDR를 입력하면 실시간 ROA 정보가 조회된다.

ROA 등록이 완료되면 비로서 Vultr에 등록할 수 있다. 그러나 완전히 등록된 것은 아니다. 최종적으로 whois에 기제된 abuse email 주소의 확인이 필요하다. BYOIP 페이지의 인증 대기 목록에서 (인증)”시작” 버튼을 누르면 Vultr에서 IPXO로 확인 이메일을 보낸다. IPXO측에서 확인을 해주면 비로서 IP 대역을 사용할 수 있다.

Vultr에 BYOIP 등록

BGP 등록 요청

우선 BYOIP를 사용할 VM을 생성해야 한다. VM 생성 및 LOA, ROA까지 준비됐으면 BYOIP를 사용할 수 있다. [Network -> BGP]에 가서 추가하면 된다.

추가시 BGP Password 칸에는 임의로 비밀번호를 만들어 입력하면 된다. BYOIP를 사용하기 위해서는 VM에 BIRD와 같은 BGP 데몬을 돌려야 한다. 즉, VM에 바로 IP가 할당되는게 아니라, VM과 상위 라우터간을 BGP로 다시 연결하는 셈이다. 이때, BGP Password는 상위 라우터에 연결하기 위한 비밀번호가 된다.

Routes we should send you는 전문가가 아니라면 Default Table을 설정하자. Full Table 설정시 Vultr이 관측하고 있는 모든 BGP 포워딩 정보가 VM에 까지 들어온다. 정확한 갯수는 모르겠지만, 아마 수십만개의 포워딩 정보가 들어올 것이다.

해당 칸을 다 입력한 후, abuse email로 최종 확인을 해야한다. 필자는 IPXO에 등록할 때 designated abuse department를 설정 안해서 그런지 몰라도, WHOIS에 IPXO의 abuse 메일 주소가 기입되어 있다. 그러므로, IPXO에 티켓을 열어서 abuse mailbox에 온 인증 절차를 확인해 달라고 해야한다. (가만히 있으면 안해준다.) 필자는 티켓을 연지 2분만에 해결받았다.

이후, IPXO와 Vultr을 오가며 티켓을 핑퐁하면 등록이 완료된다. IPXO에 이메일 인증을 해달라~ Vultr에 인증했다고 알려주고~ 그 외 필요한 요청사항 (LOA를 jpeg로 다시 올려달라는 등) 을 정리해 주면 된다.

등록 과정이 완료되면 VM에 BGP칸이 생긴다. 해당 정보대로 BGP 설정을 완료하면 된다. 참고로, 새로 등록한 prefix(ASN)을 사용하기 위해서는 VM을 재부팅 해야 한다. 확인하지는 않았으나 BYOIP를 사용할 모든 VM을 재부팅 해야 할 것으로 보인다.

BGP 등록 요청을 마무리 하고, BGP 탭이 생겼으며 BYOIP를 사용할 VM의 재부팅 까지 완료했으면 등록 과정이 끝났다.

BIRD를 이용하여 BGP 설정

/32는 IP 주소 1개를 의미한다.

Vultr에서 BYOIP를 사용하기 위해서는 VM에서 BGP 설정을 해야한다. VM에서 Vultr의 라우터에게 BGP로 IP 주소(블록)를 쏘면, 해당 VM에 대역에 맞는 패킷을 라우팅 해 준다. 라우터로 BGP를 쏜 리전에서만 외부 ISP로 BGP를 쏴준다. 그러므로 BGP 설정이 반드시 필요하다.

VM에서 BGP로 IP를 받는것은 여러 가능성을 만들어준다. /32부터 prefix에 해당하는 대역 전체까지 하나의 VM에서 사용할 수 있다. 또한, 여러개의 VM에서 같은 IP 대역을 사용할 수도 있다. 그렇기 때문에, 1개의 VM이 죽어도 바로 옆 VM로 알아서 패킷이 흘러가는 failback을 구현할 수도 있다.

BGP에서는 ASN가 필요하다. ASN은 네트워크 번호(ID)라고 생각하면 편하다. 시스템(프로토콜) 상에서 내가 누구인지와 상대가 누구인지를 구별해야 한다. 이때 구분자로 ASN이 사용된다. 별도의 ASN을 발급받지 않았다면 내부적으로 가상 ASN을 만들어준다. 가상 ASN는 VM의 BGP 탭에 표시된다.

BIRD 설치 (Ubuntu 24.04 기준)

BIRD BGP 데몬을 설치하는 방법은 간단하다.

# BIRD BGP 데몬 설치
sudo apt install bird-bgp

BGP 설정 파일은 /etc/bird에 모여있다. 해당 폴더 내에서 bird.conf가 IPv4, bird6.conf가 IPv6에 해당한다. 필자는 IPv4 블록을 사용할 것이므로, /etc/bird/bird.conf 파일을 수정한다.

여기 들어갈 설정의 뼈대는 Vultr의 BGP탭 하단의 BGP Configuration 링크에 있다. 또한, Vultr의 공식 문서에서도 설정 셈플을 제공한다. 이것을 참고하면 다음과 같은 설정을 만들 수 있다.

protocol kernel {
        scan time 60;
        import none;
}

# 60초 마다 장치 상태(dummy1의 IP 정보등) 조회.
# dummy1에 IP 추가·변경시 60초가 지나야 제대로 작동할 수도 있음.
protocol device {
        scan time 60;
}

router id 149.28.24.130(VM의 메인 IP - 라우터 IP 역할을 하게됨);

protocol bgp vultr
{
        local as 428000(내부용 가상 ASN 번호);
        source address 149.28.24.130(VM의 메인 IP);
        import none;
        export all;
        graceful restart on;
        multihop 2;
        neighbor 169.254.169.254 as 64515;
        password "PASSWORD1234(BGP 비밀번호)";
        # 혹시나 bird를 설정하다가 잘못된 대역이 BGP를 통해 외부로 빠져나가지 않도록 필터 설정
        export filter {
            if net = 89.213.249.0/24 then accept;
            reject;
        };
}

# 1) /24 대역을 BGP로 전파 (Multi-hop을 통해서 외부에 전파됨)
# 이것은 리전마다 하나만 있어도 됨. 
# 외부로 BGP를 전파하는 원천이 되므로 HA를 위해 여러곳에 둘 수도 있으나, 작동만 한다면 1곳에서만 있어도 무방함
protocol static
{
    route  89.213.249.0/24 via 149.28.24.130(VM의 메인 IP);
}

# 2) dummy 인터페이스를 만들고, 해당 인터페이스에서 ip addr 등으로 IP를 설정.
# IP를 실제로 사용하기 위해서 필요. 각 VM에 추가 해야하며, dummy1 인터페이스 설정이 필요함.
# dummy1 라는 인터페이스에서 IP 정보를 읽고 -> 상위로 IP 정보(/32)를 전파함.
protocol direct direct0
{
    interface "dummy1(더미 인터페이스 이름 기제, 아래에서 다룸)";
}

protocol static 부분을 통해 상위 ISP(upstream)에 해당 IP 대역을 알리게 된다. 상위 네트워크로 한번만 전파만 되도 되므로, 여러개의 VM을 사용하더라도 VM 한 곳에서만 있어도 된다.

bird -p 명령어를 사용하면 설정 파일에 오류가 있는지 검사 할 수 있다. restart 때리기 전에 설정 파일에 이상이 없는지 한번 확인해 보자.

protocol static 부분까지 입력후 bird를 재시작 (systemctl restart bird) 하면 외부로 IP 대역 전파가 시작된다. 필자의 경우에는 5분도 지나지 않아서 한국 KT에서 일본 도쿄 Vultr 리전으로 패킷이 잘 흘러가게 됐다.

실제로 VM에 IP 패킷을 받게 하는것은 아래의 protocol direct 부분이다. 기제된 interface의 정보를 읽은후 상위 라우터에 BGP로 dummy1에 지정된 IP를 알릴것이다. 그러면 상위 라우터가 해당되는 패킷을 VM으로 보내줄 것이다.

Dummy Interface 생성

특정 IP를 사용하기 위해서는 IP에 연결된 네트워크 인터페이스가 필요하다. 이때 더미 인터페이스가 쓰인다. 물리적인 인터페이스 없이 테스트, 내부 사용 용도로 IP만을 할당할 때 더미 인터페이스가 쓰인다. 더미 인터페이스 생성 후 IP를 설정하고 BIRD에 연결해 주면 해당 인터페이스를 통하여 통신을 하게 된다.

ip link add dev dummy1(네트워크 인터페이스 이름)  type dummy
ip link set dummy1(네트워크 인터페이스 이름) up
ip addr add dev dummy1(네트워크 인터페이스 이름) 89.213.249.1/32 (VM에서 사용할 IP주소)

네트워크 인터페이스 생성 및 IP 설정을 완료한 후, bird를 재시작 (systemctl restart bird) 하면 설정한 IP 대역을 비로서 VM에서 사용할 수 있다. VM의 메인 IP와 BGP를 통해 들고온 BYOIP IP가 동시에 공존하는 상태가 된다.

현재 설정 정보는 birdc 프로그램을 통해 확인할 수 있다. bird 자체는 BGP를 쏘는 프로그램이다. birdc는 이것을 관리하는 프로그램이다. 예를 들어, birdc show route 를 통해 현재 라우팅 상태를 확인할 수 있다.

root@bgp-jp:/etc/bird# birdc show route
BIRD 1.6.8 ready.
89.213.249.1/32    dev dummy1 [direct0 2024-09-03] * (240)
89.213.249.0/24    via 149.28.24.130 on enp1s0 [static1 2024-09-04] * (200)

모든 설정이 완료되고 BGP까지 전파가 잘 됐다면 외부에서 내부로 Ping이 날라갈 것이다. 안에서 바깥으로 Ping을 쏘고 싶다면 ping -I 설정한_BYOIP google.com 와 같이 테스트 해보면 된다. (예: ping -I 89.213.249.1 google.com)

일반적인 서버 프로그램은 VM의 메인 IP와 BYOIP 두 곳 모두에서 접속할 수 있을것이다. 하지만 각 프로그램에서 본인이 원하는 IP만을 사용하게 하려면 추가적인 설정이 필요할 수도 있다. 예를 들어, Nginx라면 server 블록의 listen 에 다음과 같이 설정해야 할 수도 있다.

server {
    listen 89.213.249.1:80;
    server_name default_server;
    ....
}

서버 프로그램이 아니라, 외부로 접속해야 하는 클라이언트 프로그램이라면 상당히 까다로워 진다. 네트워크를 사용하기 위해서는 소켓(socket)이라는 것이 쓰인다. socket을 생성할 때 bind 주소로 BYOIP를 설정해야 한다. 왠만한 프로그램에서는 이 부분을 옵션으로 빼지 않는다. 그러므로 프로그램을 소스 코드을 수정해서 컴파일 해야 할 수도 있다.

int sockfd = socket(AF_INET, SOCK_STREAM, 0);

// 사용할 VM내의 IP를 설정(bind). 
// 일반적인 프로그램에서는 이 부분의 코드를 잘 쓰지 않음. 이 부분의 코드를 추가로 작성해야 할 수도 있음.
struct sockaddr_in localaddr;
localaddr.sin_family = AF_INET;
localaddr.sin_addr.s_addr = inet_addr("89.213.249.1");
localaddr.sin_port = 0;  // 포트는 시스템에서 알아서 지정하도록 함
bind(sockfd, (struct sockaddr *)&localaddr, sizeof(localaddr));

// 일반적인 클라이언트 프로그램에서는 아래의 "외부 접속" 코드만 존재함.
struct sockaddr_in remoteaddr;
remoteaddr.sin_family = AF_INET;
remoteaddr.sin_addr.s_addr = inet_addr(server_ip);
remoteaddr.sin_port = htons(server_port);
connect(sockfd, (struct sockaddr *)&remoteaddr, sizeof(remoteaddr));

통신이 되지 않는다면

위와 같이 잘 표시된다면 곧 통신이 될 것이다. 혹시나 통신이 되지 않는다면 다음을 확인해 보자.

1. BGP는 TCP 179 포트를 사용한다. VM에서 Vultr 라우터(bird.conf 설정의 neighbor IP – 169.254.169.254) 방향으로 방화벽이 있는것은 아닌지 확인해 보자.
2. traceroute로 IP 대역에 쏴보자. 어쨌든 해당 리전쪽 국가로 넘어간다면 BGP 전파 자체는 되는 것이다.
3. 패킷은 VM의 메인 IP 및 메인 네트워크 인터페이스로 들어온다. 혹시나 iptables 또는 ufw, firewalld 같은데서 패킷이 drop되는것이 아닌지 확인해 보자.
4. 전파는 최장 48시간이 걸릴 수 있다고 한다. (실질적으로는 5분 내로 끝나는것 같다.) 조금 더 기다려보자.