사이트 간 터널은 두 사무실이 패킷을 주고받을 수 있는지라는 한 가지 질문에 답하고, 어느 지사 장비가 어느 중앙 서비스에 도달할 수 있는지라는 중요한 질문은 열어 둡니다. 터널을 상호 신뢰로 취급하면 게스트 노트북이 재무 서버와 같은 경로에 놓이게 됩니다. 해결책은 더 나은 터널이 아니라 복호화 후 적용하는 명시적 허용 목록입니다. 이 안내서는 그 목록을 정의에서 입증된 거부까지 이끕니다.

이 순서대로 작업하고 아래 정책 단계를 통과할 때까지 터널 경로를 넓히지 마십시오.

게이트웨이를 건드리기 전에 매트릭스를 작성하십시오

쓸모 있는 행은 출발지 그룹, 목적지 호스트 또는 서비스 네트워크, 그리고 애플리케이션이 실제로 쓰는 프로토콜과 포트를 지목합니다. 지사와 데이터 센터는 항목이 아닙니다. 사설 DNS와 인증 서비스는 애플리케이션이 그것 없이는 동작할 수 없을 때만 별도 행을 얻습니다.

출발지는 서브넷 편의가 아니라 역할, 즉 직원, 게스트, 관리로 묶습니다. 셋이 하나의 평면 LAN을 공유하면 게이트웨이가 네트워크 계층에서 구분할 수 없으므로 ID 제어나 세그먼트 분할이 먼저 와야 합니다. 그런 다음 각 행에 소유자와 검토 날짜를 붙여 매트릭스를 문서로 남기십시오.

출발지목적지서비스결정
지사 직원예약 앱 10.10.5.10TCP 443복호화 게이트웨이에서 허용
지사 직원서버 관리 VLAN임의암묵적 거부
게스트 Wi-Fi임의의 중앙 범위임의터널 전에 거부
관리 점프 호스트서버 VLANTCP 22 및 3389MFA와 함께 허용, 호스트 방화벽이 더 좁힘

패킷이 복호화되는 곳에서 강제하십시오

IKE와 ESP를 허용하는 규칙은 바깥 터널만 만듭니다. 내부 트래픽은 터널 인터페이스에 평문으로 도착하므로 허용 목록은 복호화 장치의 포워딩 체인, 기본 드롭, 매트릭스 행마다 하나의 규칙으로 그곳에 둡니다. Linux 게이트웨이에서는 포워딩을 켜고 필터 규칙을 물리 업링크가 아니라 터널 장치에 두는 것을 뜻하며 strongSwan 포워딩 안내서가 설명합니다.

트래픽 선택자는 라우팅 결정이지 권한 부여 결정이 아닙니다. 넓은 선택자가 두 서브넷을 모두 덮어도 라우팅에는 맞을 수 있지만, 방화벽은 여전히 한 호스트로 가는 TCP 443만 허용합니다. 선택자는 터널을 위해 협상되며 그 안에 무엇이 들어올 수 있는지를 설명하지, 특정 장치가 무엇을 쓸 수 있는지는 아닙니다. 선택자가 넓다고 해서 방화벽 규칙을 넓혀서는 안 됩니다.

iptables -A FORWARD -i tun0 -s 10.20.0.0/24 -d 10.10.5.10 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i tun0 -j DROP

NAT와 겹치는 서브넷은 규칙을 바꿉니다

지사 게이트웨이가 터널 전에 모든 호스트를 하나의 주소로 변환하면, 출발지 기반 행은 모두 그 하나의 주소로 무너집니다. 터널 트래픽 변환을 멈추거나, 규칙이 다른 것, 예컨대 변환 전에 기록한 원래 출발지 주소에 의존해야 함을 받아들이십시오. 목적지 호스트가 원래 주소가 아니라 NAT 이후 주소를 보기 때문에 먼 쪽도 같은 문제를 겪습니다.

겹치는 범위가 또 다른 함정입니다. 둘 다 192.168.1.0/24를 쓰는 두 사무실은 한쪽을 매핑하지 않고는 하나의 정책 표로 설명할 수 없고, 매핑은 충돌하지 않는 주소 지정을 대신하지 못합니다. 나중에 풀어야 할 규칙을 쓰기 전에 계획을 고치십시오.

성공만이 아니라 거부를 증명하십시오

허용된 애플리케이션만 시험하는 것은 상류 어딘가의 관대한 규칙이 같은 결과를 내기 때문에 거의 아무것도 증명하지 못합니다.

일반 지사 장치에서 의도한 서비스에 도달하고 세션 전체가 동작하는지 확인하십시오. 다음으로 닫혀 있어야 할 목적지, 예컨대 지사가 상관없는 서버의 관리 포트를 시도하고, 그것을 떨어뜨린 카운터나 로그 항목을 읽으십시오. 규칙 집합을 끄고 동작 여부를 확인하는 것은 시험을 무효로 만들고, 보는 동안 게이트웨이를 열어 둡니다.

목록을 살아 있게 유지하십시오

애플리케이션은 이동하고, 자기 애플리케이션보다 오래 사는 규칙은 아무도 소유하지 않는 구멍이 됩니다. 검토 날짜를 행에 붙이고, 서비스가 주소를 옮기면 같은 유지보수 단계에서 선택자 범위와 방화벽 규칙을 바꾸십시오.

터널 뒤에서도 호스트 수준 제한은 중요합니다: 서버 자체의 방화벽은 공개하는 서비스에 대해서만 지사 범위를 받아들여야 합니다. 두 계층이 일치하는 편이 전적으로 신뢰하는 한 계층보다 감사하기 쉽습니다.

관련 글