안녕하세요.
오늘은 AGW와 백엔드 사이에 Azure Firewall를 구성하는 테스트를 진행해 보겠습니다.
구성도는 위와 같으며 AGW의 백엔드는 VM으로 잡고 AGW subnet에서 UDR을 이용하여 강제로 방화벽을 통과하게 설정하였습니다.
위와 같이 구성할 경우 장점은 모든 트래픽을 방화벽에서 중앙 통제가 가능하다는 점입니다.
사실 AGW에서 직접 WAF를 사용하는 방법도 있겠지만 회사 상황에 따라 3rd party 방화벽을 사용하여야 할 때는 위와 같은 구성도 고려해 볼 만합니다.
# 방화벽 정책 및 UDR 설정 하기
방화벽과 UDR을 설정하기 전에 개인 애저 환경에 AGW와 VM을 배포 후 AGW의 백엔드로 VM을 잡아줍니다.
(백엔드 설정은 웹서버이니 80번 포트로 설정해 주세요.)
그리고 방화벽을 생성해 줍니다.
SKU는 아무거나 상관없는데 가격이 저렴한 basic으로 생성합니다.
이제 UDR을 생성하겠습니다.
애저 포탈에서 udr 검색하여 udr 서비스로 들어옵니다.
간단하게 이름만 설정 후 생성합니다.
일단 AGW 서브넷에 연결하기 위해 아까 생성한 UDR에서 서브넷으로 들어간 뒤 연결을 클릭합니다.
AGW가 배포되어 있는 서브넷에 할당합니다.
이제 경로를 추가하겠습니다.
아래와 같이 설정합니다.
AGW에서 백엔드로 통신을 할 때 방화벽을 거치게 하는 UDR 설정입니다.
이제 방화벽 정책을 설정하겠습니다.
생성된 방화벽으로 들어와 방화벽 정책에 들어갑니다.
방화벽 정책에서 네트워크 규칙에 들어옵니다.
아래와 같이 네트워크 허용 정책을 생성합니다.
원본 : AGW 서브넷 대역
(이곳에 AGW 프론트 엔드 IP를 쓰시면 안 됩니다. 백엔드로 보내는 통신은 AGW 내부에서 이루어지기 때문에 AGW 서브넷으로 지정해 줍니다.)
프로토콜 : TCP
대상 포트 : 80
대상 : 백엔드 서브넷 대역
(AGW에서 백엔드로 가는 요청은 허용하겠다는 의미)
위와 같이 설정하고 생성합니다.
# 테스트
이제 준비는 끝났습니다.
AGW 프런트엔드 IP를 호출해 보겠습니다.
분명히 필요한 설정은 모두 해주었는데 502 에러가 발생했습니다.
백엔드 VM에서 로그를 확인해 보겠습니다.
위 로그는 tcpdump를 이용하여 확인한 tcp 3-way handshake 로그입니다.
10.0.0.164 (AGW) → 10.0.0.149 (backend vm) SYN 패킷 발생
10.0.0.149 (backend vm) → 10.0.0.164 (AGW) SYN + ACK 패킷 발생
여기 까지는 잘 발생되나 그 후 10.0.0.164 (AGW) → 10.0.0.149 (backend vm) ACK 패킷이 있어야 하나 보이지 않습니다.
즉, AGW에서 백엔드까지 패킷이 전달은 되었지만 백엔드에서 답변이 AGW로 전달되지 못하고 있는 것으로 보입니다.
왜 이런 일이 발생할까요?
구성도를 다시 확인해보겠습니다.
분명 패킷은 백엔드까지 오고 SYN에 대한 답변 (SYN+ACK)을 보냈습니다.
이 패킷은 어떤 경로를 통해 AGW로 전달되는 것일까요?
위 그림을 보면 backend는 AGW로 답변이 나갑니다.
백엔드에서 방화벽으로 답변을 하지 않고 바로 AGW로 답변을 하는 이유는 패킷에 소스 IP가 AGW의 IP로 잡혀 있기 때문입니다.
방화벽의 역할은 패킷을 건드리지 않고 패킷이 정책상 맞는지 틀린 지만 확인하고 바로 목적지 IP로 보내는 역할을 하게 되어 패킷의 출발지 ip는 agw인 상태로 backend로 보내지게 됩니다.
해당 패킷을 전달받은 backend는 "어 출발지 ip가 agw니까 답변을 agw로 주면 되겠다"
그래서 SYN을 받은 backend는 SYN + ACK를 AGW로 바로 전달하게 되는 것입니다.
(이때 방화벽은 AGW와 Backend 사이에서 SYN + ACK 통신이 있었는지 알지 못함)
그 후 AGW는 SYN + ACK에 대한 답변으로 ACK를 backend에 보내야 하는데 UDR로 인해서 강제로 방화벽으로 가게 됩니다.
이때 방화벽은 "어 얘네 SYN + ACK 통신을 하지도 않았는데 왜 갑자기 ACK를 날리지?" 하면서 세션을 끊어버리게 되는 것입니다.
# 해결 방안
통신이 정상적으로 되지 않은 이유는 중간에 방화벽을 건너뛰었기 때문입니다.
그렇다면 정상적으로 통신이 되기 위해서는 백엔드에게 알려주어야 합니다.
"답변은 AGW가 아닌 방화벽으로 하면 된다."
여러 방안이 있겠지만 저는 2가지만 소개하겠습니다.
첫 번째
방화벽에서 SNAT를 사용하는 것입니다.
위에서 설명했듯이 방화벽은 따로 패킷을 건드리지 않기 때문에 출발지 IP가 AGW인 상태 그대로 백엔드로 보냅니다.
그래서 backend는 방화벽이 아닌 AGW로 답변을 하게 됩니다.
그렇다면 SNAT를 이용하여 출발지 IP를 AGW에서 방화벽으로 바꿔 버리면 됩니다.
이제 backend는 "어 출발지 IP가 방화벽이네? 그러면 방화벽에 답변을 해줘야겠다."라고 생각하게 되어 답변을 방화벽에 나가게 됩니다.
그러면 이제 방화벽은 아까 AGW에서 보낸 SYN에 대한 응답 패킷이 들어온 것을 인지하고 정상적으로 통신이 가능하게 됩니다.
snat 설정을 진행하겠습니다.
방화벽으로 들어가 방화벽 정책에 들어갑니다.
개인 IP 범위(SNAT) 클릭 후 항상을 클릭합니다.
이제 통신 테스트를 진행하겠습니다.
정상적으로 통신이 되는 것을 확인 가능합니다.
두 번째
두 번째 방법은 backend 서브넷에도 udr을 설정하여 AGW와 통신 시 방화벽을 통과하게 합니다.
그렇게 되면 방화벽은 중간의 모든 통신을 확인할 수 있게 되어 통신이 가능해집니다.
이제 udr을 설정해 보겠습니다.
udr을 하나 생성합니다.
그리고 백엔드 서브넷을 할당합니다.
backend 서브넷을 연결합니다.
이제 통신을 진행해 보겠습니다.
정상적으로 통신이 되는 것을 확인 가능합니다.