솔루션 서버에서 관리 대상 서버로 통신이 안된다는 것인데 고객사에서는 안 될 이유를 모르겠다고 했다.
문의 내용
솔루션 서버 Linux에서 관리 서버 Linux로 SSH 접근 불가
이하 솔루션 서버 1: A-a, 솔루션 서버 2: A-b, 관리 서버: B로 지칭하겠다.
이슈 파악하기
- A 와 B 사이의 방화벽이 존재하는가?
a. 구간을 가로막고 있는 방화벽은 없다 - B 서버의 OS 자체 보안 설정이 있는가?
a. 없다.
일단 두 내용으로 보았을 때 구성의 문제는 아닌 것 같았다.
tracepath 명령어로 패킷 추적하기
사용법은 간단하다.
tracepath -p [ssh포트 번호] [B 서버 IP]이렇게 입력하면 해당 포트를 사용해 목적지 서버까지 도달하는 동안 거친 노드를 나열해준다.
근데 이 명령어를 사용했을 때 나온 것은 출발지와 목적지. 나는 이것을 출발지와 목적지가 동일한 네트워크를 가지고 있단 뜻으로 생각했다.
tcpdump 사용해 모든 B 서버 대상 패킷 분석
네트워크 패킷을 명령에 맞게 가로채고 보여주는 툴이다. 여러 개의 옵션이 있으나 여기서는 따로 소개하지 않겠다.
주의) 아래 명령어 그대로 치면 B 서버와 통신한 모든 패킷을 보여주므로 SSH만 사용하는 게 아니라면 필히 and 조건을 걸어 tcp port를 ssh/sshd 포트로 설정할 것
# 네트워크 인터페이스 eth1:1을 사용한 B 서버 IP와 통신한 패킷 필터링
tcpdump -i eth1:1 -nn host [B 서버 IP]위 명령어를 입력하고 다른 A 서버 터미널을 열어 B 서버로 SSH 연결을 시도해 보았다.
음... A 서버에서 B 서버로 연결을 시도하기 위하여 SYN 패킷을 보낸 것은 확인했으나 SYN-ACK,RST-ACK 둘 다 오지 않았다.
이번엔 터미널을 하나 더 열여서 다른 네트워크 인터페이스도 확인해보자.
tcpdump -i eth1 -nn host [B 서버 IP]다시 SSH로 접속을 시도해보니 이번에도 똑같이 인터페이스 eth1:1에 SYN 패킷을 보낸 것이 확인되었다. 그런데 eth1로 SYN-ACK 패킷이 B 서버에서 출발해 들어온 것이었다. ???
형이 왜 거기서 나와?
이것은 솔루션 구성과 연관이 있다.
원인은 솔루션의 HA를 위한 Virtual ip 구성과 L2 스위치
보안 솔루션은 위급 상황 대비를 위해 Active-Standby HA 구성이 되어 있다. 별도의 virtual IP를 통해 서비스하며 평소 Active 서버로 운영하다가 서비스에 이상이 생길 경우 failover가 작동하여 standby 서버로 서비스하기 위해 virtual IP를 띄운다.
그런데 관리 서버 접속 로그에 virtual IP가 나오면 헷갈리니까 관리 대상 서버에 접근하기 위해 virtual IP가 활성화 되어 있을 때는 외부로 나가는 패킷은 모두 리얼 인터페이스 eth1를 거치고 나가도록 iptables를 사용한 NAT 설정이 되어있다.
virtual IP를 가진 eth1:1은 eth1의 인터페이스를 복사해 가상의 인터페이스를 만드는 것인데 이 구성들은 평소에는 문제가 없다. 다만 인터페이스를 복사할 때 MAC 주소는 원본인 eth1의 MAC 주소를 그대로 복사한다는 점인데 이 부분에서 감이 오지 않는가?
맞다. L2 스위치에 같이 물려있는 동일 네트워크 대역은 eth1:1과 eth1을 구분하지 못한다. 왜? L2 스위치는 IP로 패킷을 전달하는게 아니라 MAC 주소를 보고 패킷을 전달하는 것이다. 그래서 간단한 TCP 3 way handshake에도 이런 솔루션 구성이면 정신을 못차리는 것이다.
결론 (세줄요약)
- 솔루션 서버와 관리 대상 서버가 동일 네트워크로 L2에 같이 물려있음.
- virtual IP와 real IP의 MAC 주소가 같으니 L2가 구분하지 못함.
- eth1을 통해 나갔던 패킷이 애먼 eth1:1로 들어오는 사태
내가 필드 엔지니어 일 때 있었던 재미있는 이슈를 적어보았다. 해결 방법은 특별히 가이드하진 않았다. 원래 솔루션 도입 전에 HA 주의사항으로 미리 알려주기 때문에 원인만 파악하고 철수했었다.
