리눅스 서버를 라우터로 바꾸려면 뭘 설정해야 할까? 생각보다 손댈 게 많아요

네트워크 인터페이스 두 개 꽂았다고 라우터가 되는 건 아니에요

집이나 회사에서 쓰는 공유기, 그러니까 라우터가 하는 일을 한번 생각해보면요. 하나의 장비가 여러 네트워크(예를 들어 인터넷과 내부 LAN)를 연결해주면서, 패킷을 이쪽에서 저쪽으로 전달해주는 게 핵심이에요. 리눅스 서버에 네트워크 카드(NIC)를 두 개 꽂으면 물리적으로는 두 네트워크에 동시에 연결된 상태, 즉 "멀티홈드(multi-homed) 호스트"가 되는데요. 근데 이 상태 그대로 두면 리눅스는 그냥 양쪽 네트워크에 발을 걸치고 있는 일반 컴퓨터일 뿐이지, 라우터처럼 동작하지 않아요.

이걸 실제로 라우터/스위치처럼 동작하게 만들려면 리눅스 커널 설정부터 방화벽 규칙, 네트워크 파라미터까지 꽤 여러 군데를 손봐야 하는데요. Patrick McCanna라는 엔지니어가 이 과정을 7가지 설정 변경으로 정리해서 공유했어요. 네트워크 엔지니어링을 공부하거나, 홈랩에서 직접 라우터를 만들어보고 싶은 분들에게 정말 좋은 가이드예요.

1단계: IP 포워딩 켜기 — 가장 기본이자 핵심

리눅스 커널은 기본적으로 한 인터페이스로 들어온 패킷을 다른 인터페이스로 넘겨주지 않아요. 보안 때문이기도 하고, 일반 서버는 그럴 필요가 없으니까요. 이걸 켜주는 게 IP 포워딩(IP forwarding)인데요, 이게 뭐냐면 "내 NIC 하나로 들어온 패킷의 목적지가 다른 NIC 쪽 네트워크라면, 그쪽으로 넘겨줘"라고 커널한테 알려주는 거예요.

설정은 간단해요. sysctl net.ipv4.ip_forward=1 한 줄이면 되거든요. 영구 적용하려면 /etc/sysctl.conf에 넣어두면 되고요. IPv6도 쓴다면 net.ipv6.conf.all.forwarding=1도 같이 켜줘야 해요. 이 한 줄이 사실상 "이 머신은 이제 라우터 역할을 합니다"라고 선언하는 거라고 보면 돼요.

2단계: 리버스 패스 필터링 이해하기

리눅스에는 rp_filter(Reverse Path Filtering)라는 보안 기능이 있어요. 이건 "이 패킷이 들어온 경로가 논리적으로 맞는 경로인가?"를 검증하는 건데요. 예를 들어 eth0으로 들어온 패킷의 출발지 IP가 eth1 쪽 네트워크 대역이라면 "이거 뭔가 이상한데?" 하고 버려버리는 거예요. 스푸핑 공격을 막는 데 유용하죠.

근데 라우터는 양쪽 네트워크의 패킷을 모두 다뤄야 하잖아요. 비대칭 라우팅(패킷이 들어오는 경로와 나가는 경로가 다른 경우)도 흔하고요. 그래서 라우터로 쓸 때는 이 값을 0(끔)이나 2(느슨한 모드)로 바꿔야 해요. 2로 설정하면 "라우팅 테이블에 해당 출발지로 가는 경로가 아예 없는 경우에만" 버리는 거라, 보안과 기능 사이에서 적절한 균형을 잡을 수 있어요.

3단계: ICMP 리다이렉트 끄기

ICMP 리다이렉트는 "야, 너 나한테 패킷 보내지 말고 저쪽 라우터한테 직접 보내는 게 더 빨라"라고 알려주는 메시지인데요. 일반 호스트일 때는 유용할 수 있지만, 내가 직접 라우터 역할을 하고 있다면 이런 리다이렉트를 보내면 안 돼요. 트래픽 흐름을 내가 제어해야 하는데, 클라이언트한테 "나 거치지 말고 직접 가"라고 말해버리면 방화벽 규칙이나 NAT 같은 처리를 빠져나가게 되니까요.

net.ipv4.conf.all.send_redirects=0으로 설정하면 돼요. 받는 쪽 리다이렉트(accept_redirects)도 같이 꺼주는 게 일반적이에요.

4단계: ARP 관련 설정 조정

ARP(Address Resolution Protocol)는 IP 주소를 MAC 주소로 변환하는 프로토콜인데요. 멀티홈드 호스트에서 재미있는 문제가 생겨요. NIC가 두 개 있으면, eth0의 IP에 대한 ARP 요청이 eth1으로 들어왔을 때도 응답해버리는 경우가 있거든요. 이걸 "ARP flux" 문제라고 불러요.

이게 왜 문제냐면, 같은 네트워크 안의 다른 장비들이 혼란스러워지거든요. "어? 이 IP가 이 MAC 주소에도 있고 저 MAC 주소에도 있네?" 하면서 ARP 테이블이 꼬여버려요. 이걸 방지하려면 arp_ignore와 arp_announce 파라미터를 조정해서, 각 인터페이스가 자기 IP에 대한 ARP 요청에만 응답하도록 만들어야 해요.

5단계: NAT(네트워크 주소 변환)와 방화벽

대부분의 홈/소규모 라우터가 하는 일 중 하나가 NAT, 즉 내부 사설 IP를 외부 공인 IP로 바꿔주는 건데요. 리눅스에서는 iptables나 nftables로 이걸 설정해요. 가장 기본적인 형태가 마스커레이드(masquerade)인데, 내부에서 나가는 패킷의 출발지 IP를 라우터의 외부 IP로 바꿔치기해주는 거예요.

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE 한 줄이면 기본적인 NAT가 동작해요. 물론 실제 운영에서는 FORWARD 체인의 방화벽 규칙도 꼼꼼히 설정해야 하고요. 어떤 트래픽을 허용하고 어떤 걸 차단할지, 상태 추적(conntrack)은 어떻게 할지 등 고려할 게 많아요.

6~7단계: MTU와 MSS 클램핑, 그리고 라우팅 테이블

PPPoE나 VPN 터널을 쓰면 패킷에 추가 헤더가 붙으면서 MTU(Maximum Transmission Unit, 한 번에 보낼 수 있는 최대 패킷 크기)가 줄어들어요. 이때 MSS 클램핑을 안 해주면 "패킷이 너무 커서 못 보내겠어"라는 에러가 나면서 특정 사이트가 안 열리는 증상이 생기거든요. 이것도 iptables에서 -j TCPMSS --clamp-mss-to-pmtu 옵션으로 처리할 수 있어요.

라우팅 테이블도 직접 관리해야 해요. 어떤 목적지로 가는 패킷은 어떤 인터페이스로 보낼지 ip route 명령으로 설정하는 건데, 기본 게이트웨이 설정부터 정적 라우트 추가까지 네트워크 구성에 맞게 짜줘야 해요.

상용 라우터 vs 리눅스 라우터, 그래서 뭐가 다를까

사실 여러분이 쓰는 공유기 안에도 대부분 리눅스가 돌아가고 있어요. OpenWrt 같은 프로젝트가 바로 공유기용 리눅스 배포판이잖아요. Cisco나 Juniper 같은 상용 장비는 전용 ASIC 칩으로 하드웨어 레벨에서 패킷을 처리하니까 성능이 압도적이지만, 소규모 네트워크나 홈랩에서는 리눅스 서버로도 충분히 라우터 역할을 할 수 있어요.

최근에는 VyOS처럼 리눅스 기반의 네트워크 OS를 쓰는 사례도 많고, pfSense/OPNsense(이건 FreeBSD 기반이지만 비슷한 맥락) 같은 오픈소스 방화벽/라우터 솔루션도 인기가 많아요. 클라우드 환경에서도 AWS VPC의 NAT 인스턴스가 결국 리눅스 IP 포워딩을 쓰는 거고요.

한국 개발자에게 주는 시사점

백엔드 개발자라면 이 내용을 알아두면 네트워크 디버깅할 때 큰 도움이 돼요. "왜 서버 A에서 서버 B로 패킷이 안 가지?" 할 때, IP 포워딩이 꺼져 있거나 rp_filter 때문인 경우가 실제로 있거든요. 특히 Docker나 Kubernetes를 쓰면 컨테이너 네트워킹이 결국 리눅스 네트워크 네임스페이스와 iptables 규칙 위에서 돌아가는 거라, 이 기본기를 알면 "왜 Pod끼리 통신이 안 되지?" 같은 문제를 훨씬 빨리 잡을 수 있어요.

홈랩을 운영하시는 분들은 직접 리눅스 라우터를 구축해보는 것도 추천해요. 남는 미니PC에 NIC 하나 더 꽂고 이 설정들을 따라하면, 네트워크의 작동 원리를 체감으로 익힐 수 있거든요.

정리하자면

리눅스를 라우터로 만드는 건 NIC 꽂고 IP 포워딩 켜는 것에서 시작하지만, 실제로는 보안 필터, ARP 동작, NAT, MTU 조정까지 꽤 많은 레이어를 이해하고 설정해야 해요. 이 과정 자체가 네트워크의 핵심 개념을 배우는 최고의 실습이기도 하고요.

여러분은 리눅스로 네트워크 장비를 직접 구성해본 경험이 있나요? Docker/K8s 네트워킹 문제를 디버깅하다가 이런 저수준 설정을 건드려본 적이 있다면 경험을 공유해주세요.