사이트 간 VPN에서 무엇을 기록할까: 셀렉터와 범위

터널을 도입한 지 여섯 달 뒤 새 서브넷이 정책과 일치하지 않기 시작하는데, 공유 서버의 유일한 문서에는 사무실 VPN이라고만 적혀 있다. 이것이 셀렉터 기록이 막는 장애이며, 주소 집합은 바뀌었는데 서류는 그대로인 것이다. 기록을 제대로 쓰려면 여러 주소 집합 중 무엇을 설명하는지 알아야 하고, 내가 구성한 것이 아니라 상대가 실제로 적용하는 것을 기록해야 한다.

구성과 협상은 다르다

정책 기반 IPsec 터널에서 각 측은 자식 어소시에이션의 출발지와 목적지 범위라는 트래픽 셀렉터를 제안한다. 응답하는 측은 그 제안을 좁힐 수 있다 , 따라서 설치된 어소시에이션은 구성에 나열된 것보다 적게 포괄할 수 있다. 구성을 그대로 옮긴 기록은 그러므로 의도를 설명할 뿐 현재 보호 범위를 설명하지 않는다. 둘은 조용히 벌어지고, 터널 상태 페이지에는 그것을 지적하는 것이 없다.

두 칸을 모두 관찰한 날짜와 함께 유지한다. 구성된 셀렉터는 의도한 것이고, 협상된 셀렉터는 커널이 지금 적용하는 것이다. 둘이 다를 때 그 차이는 라우팅 버그보다 훨씬 자주 예상치 못한 장애를 설명한다.

하나의 어소시에이션이 구성된 모든 쌍을 대표하지도 않는다. 셀렉터 조합이 여러 개인 터널은 자식 어소시에이션이 여러 개로 끝날 수 있고, 그중 하나만 나열한 기록은 불완전한 목록이다. 요약하지 말고 모두 나열한다.

경로 기반 터널은 다르게 선택한다

경로 기반 인터페이스에서는 라우팅 테이블이 터널로 무엇이 들어가는지 결정하고 셀렉터는 의도적으로 넓을 수 있다. 그것은 부주의가 아니라 정당한 설계이며, 기록도 그렇게 설명해야 한다. 경로, 그것이 가리키는 인터페이스, 어떤 서비스에 도달할 수 있는지 제한하는 방화벽 정책을 적는다. 보호 범위는 의도적으로 넓고, 좁히는 일은 서비스 범위가 한다.

정책 기반 템플릿을 경로 기반 터널에 복사하면 배포가 쓰지 않는 메커니즘을 설명하는 문서가 만들어진다. 다음 엔지니어는 거기에 있을 이유가 없던 셀렉터를 찾고, 단지 문서화가 나쁠 뿐인데 터널이 잘못 구성되었다고 결론 내린다.

변환도 같은 표에 들어간다

NAT가 상대에게 다른 범위를 제시하면 원래 프리픽스와 변환된 프리픽스를 함께 기록하고, 셀렉터와 접근 규칙이 어느 단계에서 그것들을 대조하는지 적는다. 순서가 먼 쪽이 적어 둔 주소를 과연 보게 될지 결정하기 때문이다. 두 범위 중 하나만 있는 표는 완전해 보이므로 표가 없는 것보다 나쁘다.

NAT 변경 뒤에 작동하던 터널을 깨뜨리는 세부는, 셀렉터가 여전히 원래 프리픽스와 일치하고 상대가 이제 변환된 것을 받으며 그 반환 경로가 더 이상 존재하지 않는 주소를 가리킨다는 것이다. 둘이 일치하기를 멈추는 순간 아무것도 오류를 기록하지 않는다.

사설 DNS도 같은 자리에 들어간다. 해당 사이트에서 쓸 수 없는 주소로 해석되는 이름은 지원 티켓이 붙은 문서 오류이며, 그 책임은 터널에 돌아간다.

서비스 요구 사항을 붙인다

보호 범위는 허용 목록이 아니다. 어떤 서비스가 어느 출발지에서 도달 가능해야 하고, 그 뒤의 애플리케이션을 누가 소유하는지 적는다. 그 두 필드는 다른 질문에 답하며, 이를 혼동하면 보안 검토가 접근이 아니라 라우팅을 두고 다투게 된다.

그다음 규칙을 유지하는 네트워크 관리자를 지목한다. 소유자 없는 셀렉터 목록은 조용히 낡아가고, 새벽 두 시에 터널이 끊길 때 낡은 것과 틀린 것은 구별되지 않는다. 소유자는 변경이 의도적이었음을 확인할 수 있는 사람이기도 하다.

기록을 시험 계획으로 바꾼다

필요한 각 경로에 대해 대표 출발지와 목적지 호스트를 고르고 예상 경로, 서비스, 응답 게이트웨이를 적는다. 그러면 문서가 설명이 아니라 시험 계획이 된다. 아래 명령으로 살아 있는 어소시에이션을 읽고, 적어 둔 협상 줄과 비교한다.

swanctl --list-sas

다섯 줄 골격이면 보통 기록을 정직하게 유지하기에 충분하다. 아래 판은 잘리지 않고 변경 티켓에 들어간다:

sites: office <-> dc1
configured selector: 10.10.0.0/16 <-> 10.20.0.0/16
negotiated selector: 10.10.4.0/22 <-> 10.20.0.0/16
translated range: 172.16.4.0/22 -> 10.10.4.0/22
service and owner: erp:443 / finance-netops

게이트웨이에만 하는 핑은 인수 시험이 아니다. 전송 경로를 전혀 연습하지 않으므로 전달되는 모든 흐름이 실패해도 통과할 수 있다. 한쪽 호스트에서 다른 쪽 서비스로 시험하고 응답이 터널을 통해 오는지 확인한다. 핑만 통과한다면 기록은 막으려고 쓰인 전달 문제를 방금 찾아낸 것이다. strongSwan 전달 문서 Linux 피어에서 셀렉터, 경로, 전달이 어떻게 상호 작용하는지 설명한다.