blog.stackframe.dev

WireGuard의 Allowed IPs 설명

WireGuard에는 각 피어마다 Allowed IPs 라는 설정이 있다. Allowed IPs는 이 피어를 통해 보내고 받을 수 있는 패킷의 IP를 설정하여 필터링과 라우팅에 사용된다.

Allowed IPs: 10.0.0.5/32로 설정된 peer

주의할 점은 여기서 말하는 라우팅은 리눅스 시스템 라우팅과 다르다. 리눅스의 라우팅은 어떤 인터페이스로 패킷을 보낼지 정하는 거지만, WireGuard의 라우팅은 WireGuard 인터페이스에 들어온 패킷을 어떤 피어에게 보낼지 결정하는 것이다. 리눅스의 라우팅으로 WireGuard 인터페이스로 보내진 패킷에 대해서 WireGuard의 라우팅이 작동한다는 뜻이다.

WireGuard의 라우팅은 간단하다. WireGuard 인터페이스로 패킷을 보내면 목적지 IP가 Allowed IPs에 포함되는 피어를 찾고 그 피어에게 패킷을 전달하게 된다. 해당 인터페이스에 목적지 IP가 포함된 Allowed IPs를 가진 피어가 없다면 당연히 패킷은 drop된다.

필터링은 들어오는 패킷에 적용된다. 다만 들어오는 패킷의 출발지 주소가 해당 피어의 Allowed IPs에 있는지 확인한다. 그러므로 연결된 피어에게서 설정되지 않은 출발지 IP 주소의 패킷이 온다면 drop된다. 위의 라우팅에서 어떤 피어의 Allowed IPs에도 존재하지 않는 IP 주소로 패킷을 보내면 drop시키는 형태도 결과적으로 나가는 패킷에 대한 필터링이라 볼 수 있을거 같다.

한 예시로 아래와 같은 구조의 연결에 대해 생각해보자:

                peer A         <-------------------------->          peer B       <-------------------------->        peer C
             IP: 10.0.0.1                                         IP: 10.0.0.2                                      IP: 10.0.0.3
Allowed IPs: 10.0.0.2/32, 10.0.0.4/32          Allowed IPs: 10.0.0.1/32 | Allowed IPs: 10.0.0.3/32          Allowed IPs: 10.0.0.0/24
                                                             Allowed IPs: 10.0.0.4/32
                                                                        ^
                                                                        |
                                                                     peer D
                                                                  IP: 10.0.0.4
                                                     Allowed IPs: 10.0.0.1/32, 10.0.0.3/32

A, B, C, D 4개의 피어가 B를 중심으로하는 Star 형태의 네트워크로 WireGuard가 구축되어 있다. peer B에는 IP 포워딩이 켜져있다고 가정한다. 피어 아래에 쓰여져 있는 Allowed IPs는 연결된 피어에 대한 설정이다. 그러므로 B는 세가지 Allowed IPs를 가진다. 먼저 B가 패킷을 어떻게 처리하게 되는지 알아보자. A, C, D에 대해 각각 그들의 IP 주소만 허용하는 Allowed IPs가 설정되어 있다. 이것은 A, C, D가 목적지인 패킷만 그들에게 전송하며 A, C, D 자신이 출발지인 패킷만 그들에게서 수신하겠다는 의미이다. 그러므로 A, C, D가 자신에게 할당된 것 이외의 주소를 사용하거나 임의로 포워딩을 하여 패킷을 B로 보내더라도 B는 그 패킷을 무시한다. 마지막에도 설명하겠지만 D는 B의 주소를 Allowed IPs에 포함하지 않는다. 그러므로 B가 자신의 IP로 패킷을 보내더라도 D는 그 패킷을 버리기 때문에 D와는 통신이 불가능하다. 물론 A와 C가 D에게 보내는 패킷은 제대로 포워딩되며 D는 그걸 받아들이기 때문에 이들 사이의 통신은 가능하다.

이번엔 A의 Allowed IPs가 어떻게 작동하는지 보자. A에게는 10.0.0.2, 10.0.0.4 2개의 IP가 Allowed IPs에 있다. 그러므로 이 2개의 IP가 출발지 주소인 패킷을 B로부터 수신할 수 있다. 발신 또한 목적지 주소가 10.0.0.2, 10.0.0.4라면 B에게 전달된다. 그리고 10.0.0.3 주소를 가진 C가 목적지인 패킷은 갈 곳이 없으므로 드롭된다. C가 A에게 패킷을 보내더라도 Allowed IPs에 있지 않으므로 A는 무시한다.

다음은 C이다. C는 10.0.0.0/24 대역을 Allowed IPs로 사용한다. 그러므로 10.0.0.0 - 10.0.0.255 까지의 목적지 IP를 가지는 패킷을 B로 전달하며, 그 범위의 주소를 가진 peer가 보내는 C가 목적지인 패킷을 B에게서 받을 수 있다. 그러므로 B와 D랑 통신이 가능하며 A와는 패킷을 보내도 A가 무시하며 그쪽에서도 보내지 않으니 통신할 수 없다.

마지막으로 D를 보자. D는 A와 비슷하게 2개의 IP를 allowed IPs에 설정했다. 조금 다른 점은 직접적으로 연결된 B의 주소가 포함되어 있지 않다는 점이다. 여기서 착각할 수 있는 부분이 바로 직접적으로 연결된 피어는 무조건 허가되어야 한다고 생각하는 것이다. 직접적으로 연결된 피어는 단지 중간 경로일 뿐 다른 피어하고만 통신을 하고싶을 수도 있다. Allowed IPs는 송수신할 주소를 설정하는 것이기 때문에 중간 경로의 피어는 고려하지 않아도 된다. 그러므로 D처럼 B의 주소를 빼고 A와 C의 주소만 Allowed IPs에 넣어서 A와 C하고만 통신이 가능하다.

댓글