인터넷이 없어 인트라넷(내부망)을 통해 API를 통신해야하는 상황이었다.
대략적인 전체구조는 A(출발지) -> B(VPN) -> C(목적지) 이렇게 A에서 C까지 가는데
중앙에 VPN 서버가 A에서 들어온 패킷을 NAT를 통해서 C로 보내는 구조였다.
A에서는 어려울 것 없이 B가 제공하는 IP로 API 요청을 보내면 B가 알아서 C로 보내는 역할이었기
때문에 API의 응답 또한 제대로 동작하는 것을 확인했으나
이후 관리목적 차원에서 라우터를 설치하면서 해당 API 요청에 문제가 생겼다.
요청에 대한 응답은 timeout이 발생했고 원인을 VPN 또는 목적지에서 제공하는 API가
어떤 문제로인해 제대로 동작하지 않을 거라고 예상 했으나
라우터를 연결하면서 생긴 게이트웨이 문제였다.
라우터가 연결돼있지 않은 상태에서는 예를 들어서,
A의 IP가 172.15.2.2 이고
B의 IP가 172.115.1.210 일때
방화벽 규칙만 막히지 않도록 잘 설정돼 있다면 문제없이 통신된다.
이 경우 tracert를 통해 172.115.1.210으로 가는 패킷을 추적하면
제일 먼저 172.15.2.254(보통 254), 즉, 해당 대역의 게이트웨이로 패킷이 전달되는 것을
확인할 수 있다.
그러나
라우터를 설치했을 경우, tracert 를 시도했을때 게이트웨이가 라우터의 게이트웨이로 전달되었고, 그래서 B로 가지 못하는 현상이 발생해버린 것이다.
해결 방법 : 특정 IP로 패킷이 전달되도록 경로 설정하기
Windows에서는 route 라는 자체기능으로 이러한 경로 설정을 할 수 있다.
Ubuntu도 있지만 서로 사용 방법이 다른 듯 하다.
cmd를 실행하고 아래의 명령어를 입력하면 된다.
route add <목적지 IP> mask 255.255.255.255 <이더넷 게이트웨이> -p상기의 명령어는 특정 IP 하나에 대한 경로 설정 방법이다.
add를 통해 경로 설정을 추가하고
서브넷마스크를 특정 IP 하나이므로 255.255.255.255로 설정한다.
<목적지 IP>로 패킷을 전달할때 거쳐야하는 게이트웨이를 설정하고,
-p를 통해 재부팅 시에도 설정한 내용이 남아있도록 설정한다.
위의 IP들로 예를 들자면,
route add 172.115.1.210 mask 255.255.255.255 172.15.2.254 -p이렇게 될것이다.
이제 172.115.1.210으로 보내는 요청들은 172.15.2.254 게이트웨이를 통해 패킷이
전달된다.
REFERENCES
https://8ugust-dev.tistory.com/16#google_vignette
