Route Tables, 0.0.0.0 outbound -> virtual appliance로 설정 할 때의 고려사항

혹시 Route Table 사용 하세요?

Azure를 사용한다면 대부분 Virtual Network를 이용하고 있을 것이다. 요즘 AI 하시는 분들이 openai 때문에 해당 서비스만 사용하시는 경우도 간간히 보이긴 하다.

Virtual Network를 사용하는 방식은 다들 다르겠지만, 조금이라도 내가 원하는데로 트래픽을 보내고 받아보려고 한다면 Route Tables 를 활용해 봤을 것이다.

오늘은 Route Table에 대한 경험 공유를 해보려한다.

혹시 Log Analytics로 특정 데이터를 보내시나요?

조금 더 심화버전으로, Log Analytics 를 사용하여 내가 원하는 데이터를 받아보는 유저들 또한 많을 것이다. 물론 "나는 내가 올린 코드에서 모든 log들을 중앙 집중화 해서 잘 보고 있습니다." 라는 분들도 있지만, PaaS 제품을 쓰고 있다면 내가 못받아보는 log들은 궁금할 것이다. LB 까지 VM으로 구축해서 사용하여 full IaaS 기반으로만 사용하신다면 그 노력과 부지런함에 박수를 드립니다.

단적인 예로 나는 아래와 같은 PaaS 제품들의 모니터링을 Log Analytics로 보내고 있다.

• Application Gateway의 세부 데이터 (실시간 Alert용)
• Virtual Machine 안에 Log analytics Agent 설치하여 데이터 추출 (전사 security 지침)

생각보다 많이 안보내네? 비싸서 그냥 Storage Accounts로만 모든 로그들 보내는중으로 확인되었다! Log Analytics는 비싸!!

문제점 / 해결방법

문제는 Route Table의 설정과 Log Analytics로 보내지는 데이터의 조합으로 시작된다.

보통 우리는 Virtual Appliance라고 적고 방화벽이라고 읽는 제품들을 사용한다. 덧붙여, Route Table을 사용하여 모든 트래픽을 이친구에게 꺽어주고 방화벽에서 트래픽을 allow/deny 한다.

이 과정에서 inbound traffic 뿐만 아니라, outbound 또한 컨트롤하게 되는데, 위에 언급한 Log Analytics로 가는 데이터 또한 route 되어 방화벽을 타고 나가게 된다.

위에 언급한 몇개 안되는 데이터만 Log Analytics로 보내도 아래와 같이 꽤 큰 비율로 network의 한 부분을 차지하고 있었다.

위 부분은 Palo Alto에서 1주일간 데이터를 도식화 한것으로 비율을 유심히 보면, 대략 40%가까운 network traffic을 Log Analytics로 보내는데 사용되고 있는 것을 볼 수 있다.

위 상황의 Route Table 설정은 당연히 0.0.0.0을 inbound/outbound 모두 Palo Alto로 보내고 있다.

위와 같이, 목적지를 특정할 수 있는 outbound 트래픽에 대해선 아래와 같은 service tag 활용으로 트래픽을 바로 보낼 수 있다.

Log Analytics는 AzureMonitor의 service tag에 포함되어 있기에, 위와 같이 next hop을 internet으로 설정해주면 아래와 Log Analytics로 가는 traffic들은 모두 internet으로 바로 나가게 된다.

설정한 기간은 조금 다르지만, azure-log-analytics라고 기록된 traffic들이 모두 사라진 것을 확인할 수 있다.

마치며

참고로 Log Analytics가 아닌, Storage Account로 바로 저장하는 것 또한 같이 사용하고 있다면, 위 방법대로 적용하는 것에 대한 걱정은 조금 덜어도 된다. service tag로 Storage가 따로 있기 때문에, Log Analytics로 가는것만 internet으로 보내고 Storage Account로 보내는 것은 원래 방식 그대로 보내게 된다.