안녕하세요 한 회사에서 근무하고 있는 네트워크 담당자입니다.
저희 네트워크망 구성이 fortigate 방화벽 - 스위치 - 클라이언트 순서입니다.
방화벽에서 L3 역할까지하며, VLAN도 방화벽에서 나누어서 사용하고 있습니다.
최근 nac장비 도입으로 스위치 아래에 nac장비 추가가 되었는데요 ( VLAN 12 )
VLAN 12는 fortigate에 설정되어 있으며 ip는 192.168.15.1 입니다.
기본 통신시(클라이언트에서볼때) 192.168.15.1은 기존 fortigate 맥주소로 되어있다가, 차단이 필요할때 nac장비가 192.168.15.1은 자기 맥주소로 arp를 광고하여 nac을 거쳐서 통신한다고 전달받았습니다.
허나 클라이언트에서 패킷 확인시 192.168.15.1이 fortigate 맥으로도 잡히고, nac맥으로도 계속해서 변경되면서 잡힙니다.(해당증상으로 통신장애가 일어납니다)
양쪽에서 192.168.15.1은 자기 mac이라고 광고하고 있으니 문제가 일어나고 있는걸로 보입니다.
nac엔지니어에게 물어보니 nac은 IP변경도 안되고 통신차단이 필요하면 클라이언트 arp 테이블이 nac의 맥주소로 바뀌어야 한다고 주장하고 있습니다.
포티엔지니어는 192.168.15.1이 자기 IP로 설정되어있으니 arp 리퀘스트를 뿌리는것이고, arp 리퀘스트 주기변경이나 arp 브로드캐스팅을 뿌리지 않는 설정은 없다고 합니다.
혹시 nac엔지니어분이나 포티게이트 엔지니어분들이 계실까요?
변경해볼 설정이 있을지.. 자문을 구해봅니다..
혹은 비슷한 증상이셨을때 해결하셨던 경험이 있으신지 여쭤봅니다..
감사합니다!
4개의 답변이 있습니다.
저희도 지금 NAC 도입을 하고있고 글쓴이 분과 동일한 증상을 확인하였습니다. (네트워크 환경도 동일)
해당부분 관련되서 NAC과 포티넷 엔지니어 삼자대면으로 확인하였지만 설정변경으로는 조치할수 없었습니다.
업체측에서 내놓은 조치 방안은 방화벽 하단에 L3 스위치를 두어 L3스위치에서 DHCP을 관리 및 VLAN 관리를 하는것이었습니다.
당장 L3스위치를 설치할수는 없기에....
현재 문제는 말씀하신 증상으로 인해 NAC 적용시 차단페이지가 안나오는것입니다. (맥북에서 증상이 더 많이 나옴...)
그래서 저같은 경우에는 NAC 전체 적용 전 사용자 PC에 에이전트를 배포하고, 호스트체크 및 사용자 인증과 같은 정책을 미리 성립 시켜놓고 적용을 하고자 합니다.
해결책이 있다면 저도 꼭 알고싶네요 !
NAC도 다양한 종류가 있습니다.
에이전트를 각 클라이언트마다 설치해서 작동되는 에이전트 방식도 있고, 에이전트 설치 없이 통제하는 장비에서 제어하는 Agentless 방식도 있고...
VLAN 방식 NAC, ARP 방식 NAC, DHCP 방식 NAC, 802.1X 방식 NAC 등의 다양한 종류가 있기 때문에 NAC이라고 다 같은 NAC이 아닌것 같고요.
말씀하신 내용으로 봐선 ARP 방식 NAC이 아닐까 싶은데요.
ARP 주소를 조작해서 클라이언트에게 게이트웨이 주소를 조작해서 인가되지 않은 클라이언트에게 잘못된 게이트웨이 주소를 알려줘서 인터넷을 차단 시키는 형태의 NAC이 아닐까 싶은데요.
게이트웨이 주소를 변경시켜서 인터넷을 차단시키는 용도라면 NAC 보다는 방화벽 장비의 기능을 이용해서 처리하는게 낫지 않을까 하는 생각이 들어 보이고...
일반적으로 NAC은 클라이언트가 최신 패치가 되어 있는지 여부, 특정 소프트웨어가 설치되어 있는지 여부, 특정 정책을 만족하는지 여부 등등의 클라이언트 상태를 감지해서 클라이언트가 네트워크에 접속하지 못하게 만드는 목적으로 많이 도입하지 않을까 싶어 보이고...
각 클라이언트에 에이전트를 설치해서 구현하는 NAC을 도입하는게 클라이언트 제어를 좀 더 제대로 할 수 있지 않을까 하는 생각이 드네요.
추가적으로 확인된것 정정드려요..
192.168.15.1 은 포티게이트
192.168.15.254는 nac장비
192.168.15.100은 클라이언트
클라이언트입장에서 192.168.15.1 은 포티게이트 mac주소.
클라이언트에서 통신시도시 arp request를 포티게이트로 보냄.
nac이 해당 클라이언트가 비인가 pc로 인식했을경우 arp request에 대한 arp reply를 nac의 mac주소로 변경하여 차단패킷 발송.
차단패킷을 nac의 mac주소로 변경하여 보내지만, 포티게이트에서 계속해서 뿌리는 arp 브로드캐스팅 및 who - has arp 패킷으로 인하여 차단이 제대로안됨 ( 통신장애발생 )
nac 장비 쓰고계시는 분들은 어떤 구성으로 쓰고계신지 궁금하네요 .
같은 ip를 두 장비가 점유하면 충돌이 발생하지요. 나중에 들어온 것이 잘못 아닐까요? nac이 어떤 방식으로 작동하는지 모르지만 게이트웨이 역활을 한다면 기존 장비와 충돌을 고려해서 세팅해야지요. 포티쪽과도 미리 협의하고 진행했어야지요. 우린 그런거 모르니 다른것을 바꿔라하는 것은 너무 무책임해 보이네요.
nac를 도입하기 전에 이상이 없다가 nac 도입하고 문제가 발생하면 nac 측에서 적극적으로 원인을 찾고 해결법을 찾는게 맞다고 생각합니다.
merry2221 | 2년 이상 전
답변 감사드립니다.
미팅하자고..하는데..
nac쪽에서 솔루션을 찾아주셔야죠 ㅠㅠ 맞습니다..