CentOS 7 다중 default route/gateway 설정

한 개의 서버가 여러개의 서브넷에 연결되는 경우가 존재하고 어떤 서브넷에 속한 ip를 사용하냐에 따라 사용될 라우터도 달라집니다.

ip route 명령어를 통해 라우팅 테이블을 작성할 수 있지만, 전통적인 방식의 라우팅 테이블은 dst 대역에 따라서면 라우팅 테이블을 작성할 수 있었고, 그렇게 때문에 default route(r)는 한 개만 가질 수 있었습니다.

 

본 포스팅은, 서로 다른 서브넷에 속한 ip를 여러개 사용하면서 각자의 서브넷마다 default route를 설정하는 방식을 소개합니다.

 

 

서버 환경 

여러개의 서브넷을 가지는 경우는 일반적으로 여러개의 라우터 및 스위치와 연결되있음을 의미합니다.

본 포스팅 환경은 vlan 기술을 통해 가상으로 나뉘어진 여러개의 LAN에 연결되었습니다.

(vlan 기술을 사용하게되면 물리적인 네트워크 장비가 여러개의 LAN, 서브넷을 제공할 수 있습니다.)

el 7계열의 vlan tagging 방법 : https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/networking_guide/sec-configure_802_1q_vlan_tagging_using_the_command_line

10.4. Configure 802.1Q VLAN Tagging Using the Command Line Red Hat Enterprise Linux 7 | Red Hat Customer Portal

# Centos7
# 네트워크 관리 서비스: network.service

$ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether 00:54:57:b5:08:da  txqueuelen 50000  (Ethernet)
        ...

eth0.10: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.66.240.78  netmask 255.255.240.0  broadcast 172.66.255.255
        ether 00:54:57:b5:08:da  txqueuelen 1000  (Ethernet)
        ...

eth0.20: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.222.106.18  netmask 255.255.254.0  broadcast 172.222.107.255
        ether 00:54:57:b5:08:da  txqueuelen 1000  (Ethernet)
        ...

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        ...

 

라우팅 설정

맨 위에서 설명했듯이 예전 전통적인 방식은 dst address 대역만으로 라우팅 table을 관리했지만, 더 다양한 방식의 라우팅 테이블일 지원하기 위해서 리눅스 커널은 여러개의 라우팅 테이블을 구성할 수 있고 특정 규칙에 따라 어떤 라우팅 테이블일 사용할지 정할 수 있습니다.

iproute2 패키지를 사용하면 사용자 수준에서 리눅스 커널의 네트워킹을 제어할 수 있습니다.

https://wiki.linuxfoundation.org/networking/iproute2

networking:iproute2 [Wiki]

 

참고로 리눅스 커널은 OS의 핵심이지만 OS를 구성하는 모놀로틱한 하나의 바이너리 프로그램에 불과합니다.

OS는 영구적인 시스템 구성을 위해서 파일시스템이나 기타 소프트웨어등을 함께 병행하여 사용합니다.

 

그중 iproute2에 포함된 ip, tc등의 명령어는 유저 수준에서 리눅스 커널의 네트워크 계층을 제어할 수 있지만 영구적이진 않으며 재부팅할 경우 모두 풀리게됩니다. 지속적인 네트워크 계층을 구성하기 위해서 보통 네트워킹 관리용 서비스 데몬을 통해 관리합니다.

ex) Ubuntu의 netplan, Centos의 NetworkManager 등등

 

본포스팅에서는 network.service를 사용하고 있으며, network.service는 /etc/sysconfig 및 /etc/sysconfig/network-scripts 하위의 파일들을 통해 네트워킹을 관리합니다. 참고로 network.service는 iproute2 패키지를 사용하여 네트워킹 관리 방식을 추상화한 쉘스크립트의 모음으로 운영합니다.

 

 

ip rule 명령어를 통해 조건에 따라 다른 라우팅 테이블을 사용하도록 설정합니다.

참고: https://www.man7.org/linux/man-pages/man8/ip-rule.8.html

ip-rule(8) - Linux manual page

## default table에 default 라우팅 설정
# 일반적으로 시스템(서버)가 특별히 src ip를 지정하지 않으면 사용하는 인터페이스(ip)입니다.
$ ip route add default via 172.66.240.1 dev eth0.10

# 영구 설정을 원할 경우, 파일로 구성 가능
$ cat /etc/sysconfig/network
NETWORKING=yes
HOSTNAME=ahsung-test
GATEWAY=172.66.240.1

# 혹은 route-{interface}파일에도 추가 가능
$ cat /etc/sysconfig/network-scripts/route-eth0.10
default via 172.66.240.1 dev eth0.10

 

## 라우팅 테이블 추가 10, 20
# 헷갈리지 않게 number와 name을 동일하게 가져갔습니다.
# 보통 명령어에서 table을 지정할때 name으로 지정합니다.
cat /etc/iproute2/rt_tables
#
# reserved values
#
255	local
254	main
253	default
0	unspec
#
# local
#
#1	inr.ruhep
## 10, 20 추가!
10      10
20      20


## eth0.10의 default route 추가
ip route add 172.66.240.0/20 dev eth0.10 table 10
ip route add default via 172.66.240.1 dev eth0.10 table 10

## eth0.20의 default route 추가
ip route add 172.222.106.0/23 dev eth0.20 table 20
ip route add default via 172.222.106.1 dev eth0.20 table 20

## table 10 rule 추가
# src_ip가 172.66.240.78/32 대역인 경우 라우팅 테이블 10 참고
ip rule add from 172.66.240.78/32 table 10

## table 20 rule 추가
# src_ip가 172.222.106.18/32 대역인 경우 라우팅 테이블 10 참고
ip rule add from 172.222.106.18/32 table 20

## 적용 확인 명령!
$ ip route show [default] # 변화 없음
$ ip route show table 10
$ ip route show table 20
$ ip rule show

# 재부팅후 설정 유지를 위한 file 설정
$ cat /etc/sysconfig/network-scripts/route-eth0.10
172.66.240.0/20 dev eth0.10 table 10
default via 172.66.240.1 dev eth0.10 table 10

$ cat /etc/sysconfig/network-scripts/route-eth0.10
172.222.106.0/23 dev eth0.20 table 20
default via 172.222.106.1 dev eth0.20 table 20

$ cat rule-eth0.10
from 10.61.240.99/32 table 10

$ cat rule-eth0.10
from 211.231.106.18/32 table 20

# 파일의 경우 network 데몬을 restart해야 적용 / 혹은 서버 reboot
$ systemctl restart network.service

 

 

 

정상 작동 확인!!

# 인터페이스 명을 넣으면 ip rule이 적용되지 않고 default table을 사용함
# eth0.20은 default table을 사용하면 정상적으로 라우팅이 가능한 경로가 없어 실패!
$ ping -I eth0.20 <anything ip>

# src_ip를 직접 넣으면 정상 작동!
$ ping -I 172.222.106.18 <anything ip>

# curl 같은 명령어는 인터페이스명을 넣든, ip를 넣든 둘다 정상 작동함
$ curl google.com --interface 172.222.106.18
$ curl google.com --interface eth0.20

tcpdump icmp 명령어로 첫번째 케이스의 패킷 상태를 뜯어봤을 때,  src와 dst모두 eth0.20의 ip를 보냈으나 unreachable 즉 경로를 못 찾았다.

그렇나 curl은 상관없이 잘 적용됬다.., 예전 소켓프로그래밍 경험상 tcp 소켓을 처음 생성할 때, 인터페이스로 지정하든 ip로 지정하던 별로 상관은 없었다. 즉, 어쨋든 ip 계층에서 잘 인식하고 ip rule에 제대로 걸리지 않을까?

 

icmp/ping 프로세스는 raw 소켓을 사용함 (L3 계층 수준의 소켓) raw 소켓 프로그래밍을 해보진 않았지만 이미 소켓자체가 L3를 구현하는 계층이다보니 eth0.20을 넣었을 때, eth0.20의 ip 정보가 아니라 정말 L2수준의 인터페이스 정보만 넘어간게 아닌가 싶다..

쨋든 raw 소켓을 사용할때, 인터페이스를 지정하면 ip rule보다도 더 저수준에서 동작하기 때문에 그냥 default table을 사용한게 아닐가 추측함/..

일단 raw 소켓은 패킷 하나하나 단위로 컨트롤이 가능하고 스스로 src_ip, dst_ip 조작을 할 수 있으므로 인터페이스를 ip로 인식하는게 아닌, MAC 주소 수준의 계층으로 인식할 가능성이 높아보이긴한다.

 

 

참고

리눅스는 네트워크 인터페이스에 ip를 할당하지만 실질적으로 둘 사이에 아주아주 강력한 연결성을 갖지는 않는다. 커널 파리미터로 강력하게 만들 수는 있다.

예로, ip를 네트워크 인터페이스에 할당하긴 하지만 OS가 인식하는 L3 계층 입장에서는 그냥 이런 ip들이 내가 쓸 수 있게 등록되엇구나~~ 하는 정도일뿐 실제로 할당된 인터페이스를 통해서만 해당 ip 패킷이 들어오게끔 강제하진 않는다.

 

실제로 eth0, eth1 두개에 각각 다른 ip를 할당해도 eth0로만 패킷이 들어올 수 있고, eth1은 물리적으로 스위치와 연결이 안되있어도 상관 없다. (단, eth1에 할당한 ip가 eth0가 물리적으로 연결된 스위치를 통해 라우팅될 수 있는 ip이어야한다. ex) eth0, eth1 모두 같은 서브넷 ip 사용)

outbound도 마찬가지임, eth1에 할당된 ip가 eth0를 통해서 나갈 수 있으면 나가기도함, eth1에 ip를 할당했다고 해서 eth1의 ip를 src ip로 지정해도 eth0로 나갈 수 있으면 라우팅되서 나갈 수도 있음 특히 eth1가 실제로 사용불가능한 인터페이스라면 더욱더

(eth0 또한 물리적으로 eth1의 ip 라우팅이 안되면 당연히 unreachable)

 

 

 

refer: https://stackbees.co/post/multiple-default-route-linux/

Configure Multiple Default Routes, Linux