사내 인프라 신규 구축 — Dual WAN 회선 이중화와 망 분리

동기

회사가 신사옥으로 옮기면서 네트워크를 처음부터 다시 깔 기회가 생겼습니다. 그전 사무실은 가정용 공유기 한 대에 모든 트래픽이 한 망으로 섞여 있었고, 회선이 끊기면 사무실 전체가 같이 멈췄습니다.

회선 이중화와 망 분리, 그리고 직원 VPN 과 외부 협력사 VPN 의 분리를 공사 단계에서 정해 두는 것을 목표로 잡았습니다. 나중에 붙이려면 이미 자리를 잡은 기기를 전부 다시 옮겨야 하는 항목들입니다.

내가 담당한 트랙

네트워크는 전부 제가 했습니다 — 엣지 라우터 구성, 회선 이중화, VLAN 설계, 방화벽, VPN 두 인스턴스, 그 뒤의 운영과 설정 감사까지입니다. 항목별 내역은 오른쪽 「주요 업무」에 있습니다.

망을 셋으로 나누고 회선을 둘로 늘리기

엣지 라우터 한 대 위에서 망을 사무망·서버망·관리망으로 갈랐습니다. 관리망에는 네트워크 장비만 두고, 서버망은 주소를 자동으로 나눠 주지 않고 고정으로만 줍니다. 서버 주소가 바뀌지 않는다는 규칙을 사람이 기억해서 지키는 것에서 라우터가 강제하는 것으로 옮기려는 것입니다.

VPN 은 인스턴스를 둘로 나눴습니다. 직원용과 외부 협력사용이 같은 라우터에서 돌지만 포트와 대역이 다르고 갈 수 있는 망이 다릅니다. 협력사 쪽은 관리망으로 못 가고 라우터 자신의 서비스에도 못 붙습니다. 한 인스턴스에 둘을 같이 두면 그 구분을 규칙 목록으로만 유지해야 하는데, 대역이 갈려 있으면 규칙 한 줄로 끝납니다.

회선은 KT 와 LG U+ 를 둘 다 살려 두고 새 연결을 나눠 보냅니다. 나누는 일은 연결 분류기(per-connection-classifier)가 하고, 한쪽이 끊기면 남은 경로로 넘어갑니다. VPN 접속점은 동적 DNS 로 발행해서 회선 쪽 주소가 바뀌어도 사람들의 설정 파일을 다시 배포하지 않습니다.

옮기는 일은 라우터 설정에서 끝나지 않습니다. 매일 쓰는 기기가 새 망에 붙어야 옮긴 것이 되는데, 그 마지막 한 칸이 아직 남아 있습니다. NAS 는 두 망에 각각 한 발을 걸치기로 해 두고 사무망 쪽은 주소만 잡아 놓은 상태이고, 무선 AP 도 컨트롤러 등록까지는 됐지만 주소를 고정하는 단계가 남았습니다.

은행 사이트에서 로그인이 풀린다는 말

회선을 둘로 늘린 뒤에 사람들이 은행과 정부 사이트에서 로그인이 자꾸 풀린다고 했습니다.

원인은 연결을 어느 회선으로 보낼지 고를 때 쓰는 해시의 입력이었습니다. 출발지와 목적지 주소에 포트까지 넣어 해시를 만들고 있었는데, 브라우저는 새 탭이든 이미지든 요청마다 새 연결을 열고 그때마다 운영체제가 다른 포트를 붙입니다. 포트가 하나 바뀌면 해시값이 달라지고, 같은 사이트로 가는 다음 요청이 다른 회선으로 나갑니다. 사이트 쪽에서 보면 방금 로그인한 주소와 다른 주소에서 요청이 오는 것이라 세션을 버립니다.

해시 입력에서 포트를 뺐습니다. 주소만 보면 같은 PC 에서 같은 사이트로 가는 연결은 언제나 같은 회선을 씁니다. 바꾼 뒤에 자기 주소를 알려 주는 사이트에 다섯 번씩 물어 회선이 고정되는 것을 확인했고 두 회선의 분배 비율도 그대로였습니다. 바꾼 내용은 사무실 사람들이 읽을 수 있는 말로 따로 적어 돌렸습니다.

대가가 있습니다. 해시에 넣는 값이 줄어든 만큼 분배가 덜 고르게 될 수 있습니다. 사용자가 스무 명 정도라 목적지가 몇 곳으로 몰리면 한쪽 회선에 쏠릴 수 있는데, 실제로는 접속하는 곳의 주소가 흩어져 있어 문제가 되지 않았습니다.

주석과 조건이 어긋난 규칙 하나

어느 날 아침 사무실에서 이름 해석이 느려졌습니다. 라우터가 DNS 프록시를 하고 있었는데 외부에서 쿼리가 쏟아져 들어와 동시에 처리할 수 있는 자리를 다 차지했고, 내부에서 낸 쿼리가 그 뒤에 밀렸습니다. 급한 것은 사무실 기기들이 공용 DNS 를 직접 쓰도록 바꿔 걷었는데, 라우터가 배포하는 값만 바꿔서는 끝나지 않아 옛 값을 들고 있는 기기는 한 대씩 갱신해야 했습니다.

원인은 그날 라우터 설정을 처음부터 훑다가 나왔습니다. 들어오는 트래픽을 거르는 규칙 하나에 나머지는 내부에서 온 것만 받는다는 주석이 달려 있었는데, 정작 출처를 보는 조건이 그 규칙에 없었습니다. 주석대로 읽으면 내부 전용이고 실제로는 외부에서 온 것도 받고 있었습니다. 조건을 채우고, 목록 맨 끝에 아무 규칙에도 걸리지 않은 것을 버리는 규칙을 두고 기록을 켰습니다. 켠 뒤 19분 동안 버린 건수가 60건에서 975건으로 늘었고 대상은 대부분 DNS 포트였습니다.

같은 감사에서 같은 형태가 더 나왔습니다. 이미 치운 10G 스위치의 설정이 라우터에 남아 있었고, 테스트로 만든 VPN 피어가 지워지지 않은 채 있었습니다. 설계 문서와 현장을 대조한 표에서는 서버망에 붙어 있어야 할 장비가 한 대도 없었습니다.

규칙 순서도 한 번 걸렸습니다. 새 규칙을 넣어도 위에 있는 넓은 규칙이 먼저 잡아 버리면 넣은 규칙은 아무 일도 하지 않습니다. 그래서 넣기 전에 설정을 뜨고 넣은 뒤에 순서를 다시 확인합니다.

배운 점

• 나가는 길을 하나 더 만들면 어느 쪽으로 보낼지 정해 줘야 하는 자리가 트래픽 종류마다 따로 생깁니다. 라우터를 통과하는 트래픽에는 배정 규칙을 걸어 뒀는데 라우터가 스스로 내는 응답에는 안 걸려 있어서, VPN 이 한 사람에게만 안 붙는 형태로 드러났습니다. 켤 때는 안 보이는 자리입니다.
• 설정과 주석은 스스로 맞다고 주장하는데, 어긋나 있어도 아무 에러가 나지 않습니다. 감사에서 나온 것이 전부 그 형태였습니다.
• 진단의 입구가 사람의 말이었습니다. 라우터 쪽 숫자만 보고 있었으면 회선 분배는 거의 절반씩으로 정상이었습니다.