영사 + iptables = :3

2010년에 회사는 와가이밍 50개의 서버와 간단한 네트워크 모델(백엔드, 프런트엔드, 방화벽)이 있었습니다. 서버 수가 증가하고 모델이 더욱 복잡해졌습니다. 스테이징, ACL이 있는 격리된 VLAN, VRF가 있는 VPN, L2에 ACL이 있는 VLAN, L3에 ACL이 있는 VRF가 있습니다. 머리가 돌고 있나요? 나중에는 더 재미있을 것입니다.

서버가 16대일 때, 너무 많은 이기종 세그먼트로 인해 눈물 없이 작업하는 것이 불가능해졌습니다. 그래서 우리는 또 다른 해결책을 생각해냈습니다. 우리는 Netfilter 스택을 가져와 Consul을 데이터 소스로 추가했고 빠른 분산 방화벽을 얻었습니다. 그들은 라우터의 ACL을 교체하고 이를 외부 및 내부 방화벽으로 사용했습니다. 도구를 동적으로 관리하기 위해 우리는 제품 네트워크에 대한 사용자 액세스 관리부터 네트워크 세그먼트를 서로 격리하는 것까지 모든 곳에서 사용되는 BEFW 시스템을 개발했습니다.

그는 모든 것이 어떻게 작동하는지, 그리고 왜 이 시스템을 자세히 살펴보아야 하는지 알려줄 것입니다. 이반 아가르코프 (안무어)는 회사 민스크 개발 센터 유지 관리 부서의 인프라 보안 그룹 책임자입니다. Ivan은 SELinux 팬이고 Perl을 좋아하며 코드를 작성합니다. 정보 보안 그룹의 수장으로서 정기적으로 로그, 백업, R&D 작업을 통해 Wargaming을 해커로부터 보호하고 회사 내 모든 게임 서버의 운영을 보장합니다.

역사 정보

우리가 어떻게 했는지 말씀드리기 전에, 처음에 어떻게 이 일을 하게 되었는지, 그리고 그것이 왜 필요했는지 말씀드리겠습니다. 이를 위해 9년 전인 2010년으로 돌아가 월드 오브 탱크(World of Tanks)가 막 등장했습니다. Wargaming에는 약 50개의 서버가 있었습니다.

회사 서버 성장 차트.

우리는 네트워크 모델을 가지고 있었습니다. 그 당시에는 최적이었습니다.

2010년 네트워크 모델.

프런트엔드에는 우리를 무너뜨리려는 악당들이 있지만 방화벽이 있습니다. 백엔드에는 방화벽이 없지만 거기에는 50개의 서버가 있습니다. 우리는 그것을 모두 알고 있습니다. 모든 것이 잘 작동합니다.

4년 만에 서버 함대는 100배, 5000개로 늘어났습니다. 최초의 격리된 네트워크가 나타났습니다. 즉, 준비 단계: 프로덕션으로 이동할 수 없었고 그곳에서 위험할 수 있는 일이 실행되는 경우가 많았습니다.

2014년 네트워크 모델.

관성에 따라 우리는 동일한 하드웨어를 사용했으며 모든 작업은 격리된 VLAN에서 수행되었습니다. ACL은 일종의 연결을 허용하거나 거부하는 VLAN에 기록됩니다.

2016년에는 서버 수가 8000개에 이르렀고 워게이밍이 다른 스튜디오를 흡수하고 추가 제휴 네트워크가 등장했습니다. 우리 것 같지만 꼭 그렇지는 않습니다. VLAN은 종종 파트너에게 작동하지 않으며 VRF와 함께 VPN을 사용해야 하며 격리가 더욱 복잡해집니다. ACL 절연 혼합물이 증가했습니다.

2016년 네트워크 모델.

2018년 초까지 기계 보유 대수는 16개로 늘어났습니다. 000개 세그먼트가 있었고 재무 데이터가 저장된 폐쇄형 세그먼트를 포함하여 나머지는 계산하지 않았습니다. 컨테이너 네트워크(Kubernetes), DevOps, VPN을 통해 연결된 클라우드 네트워크(예: IVS)가 등장했습니다. 규칙이 너무 많아서 고통스러웠어요.

2018년 네트워크 모델 및 격리 방법.

격리를 위해 우리는 L2에 ACL이 있는 VLAN, L3에 ACL이 있는 VRF, VPN 등을 사용했습니다. 너무 많은.

문제

모두가 ACL과 VLAN을 사용하고 있습니다. 뭐가 문제 야? 이 질문에 해롤드는 고통을 숨긴 채 대답할 것이다.

많은 문제가 있었지만 XNUMX개의 ​​큰 문제가 있었습니다.

• 새로운 규칙에 대한 기하학적 가격 인상. 각각의 새로운 규칙은 이전 규칙보다 추가하는 데 더 오랜 시간이 걸렸습니다. 먼저 해당 규칙이 이미 있는지 확인해야 했기 때문입니다.
• 세그먼트 내부에는 방화벽이 없습니다.. 세그먼트는 어떻게 든 서로 분리되어 있었고 내부에는 이미 리소스가 충분하지 않았습니다.
• 규칙은 오랫동안 적용되었습니다. 운영자는 한 시간 안에 하나의 로컬 규칙을 직접 작성할 수 있습니다. 글로벌 작업에는 며칠이 걸렸습니다.
• 감사 규칙의 어려움. 더 정확하게 말하면 불가능했습니다. 첫 번째 규칙은 2010년에 작성되었으며 작성자 대부분은 더 이상 회사에서 근무하지 않습니다.
• 낮은 수준의 인프라 제어. 이것이 주요 문제입니다. 우리는 우리나라에서 무슨 일이 일어나고 있는지 잘 몰랐습니다.

2018년에 한 네트워크 엔지니어가 "ACL이 더 필요합니다."라는 말을 들었을 때의 모습은 다음과 같습니다.

솔루션

2018년 초에 이에 대해 뭔가 조치를 취하기로 결정했습니다.

통합 가격은 지속적으로 증가하고 있습니다. 시작점은 장치의 메모리 부족으로 인해 대규모 데이터 센터가 격리된 VLAN 및 ACL 지원을 중단했다는 것입니다.

해결책: 우리는 인적 요소를 제거하고 최대한의 액세스 제공을 자동화했습니다.

새로운 규칙을 적용하는 데는 오랜 시간이 걸립니다. 해결책: 규칙 적용 속도를 높이고, 분산 및 병렬화합니다. 이를 위해서는 rsync 또는 SFTP 없이 수천 개의 시스템에 규칙이 자체적으로 전달되도록 분산 시스템이 필요합니다.

세그먼트 내부에는 방화벽이 없습니다. 동일한 네트워크 내에 서로 다른 서비스가 나타날 때 세그먼트 내의 방화벽이 우리에게 오기 시작했습니다. 해결책: 호스트 수준의 방화벽(호스트 기반 방화벽)을 사용하십시오. 거의 모든 곳에서 Linux를 사용하고 iptables를 사용하는 경우 이는 문제가 되지 않습니다.

감사 규칙에 어려움이 있습니다. 해결책: 검토 및 관리를 위해 모든 규칙을 한 곳에 보관하여 모든 것을 감사할 수 있습니다.

인프라에 대한 통제 수준이 낮습니다. 해결 방법: 모든 서비스의 목록을 작성하고 서비스 간 액세스를 수행합니다.

이는 기술적인 프로세스라기보다는 관리적인 프로세스에 가깝습니다. 때로는 일주일에 200~300개의 새로운 릴리스가 있을 때도 있습니다. 특히 프로모션이나 휴일 기간에는 더욱 그렇습니다. 또한 이는 DevOps의 한 팀에만 해당됩니다. 릴리스가 너무 많아서 어떤 포트, IP 및 통합이 필요한지 확인하는 것이 불가능합니다. 따라서 우리는 팀에 "그나저나 거기에 무엇이 있고 왜 그런 이야기를 꺼냈나요?"라고 질문할 특별히 훈련된 서비스 관리자가 필요했습니다.

우리가 모든 것을 출시한 후 2019년의 네트워크 엔지니어는 이렇게 보이기 시작했습니다.

영사

우리는 서비스 관리자의 도움으로 찾은 모든 것을 Consul에 넣고 거기에서 iptables 규칙을 작성하기로 결정했습니다.

우리는 어떻게 이 일을 하기로 결정했나요?

• 우리는 모든 서비스, 네트워크 및 사용자를 수집합니다.
• 이를 기반으로 iptables 규칙을 만들어 보겠습니다.
• 우리는 제어를 자동화합니다.
• ....
• 이익.

Consul은 원격 API가 아니며 모든 노드에서 실행되고 iptables에 쓸 수 있습니다. 남은 것은 불필요한 것을 제거하는 자동 제어 장치를 만드는 것뿐입니다. 그러면 대부분의 문제가 해결될 것입니다! 나머지는 진행하면서 해결하겠습니다.

왜 영사입니까?

그 자체로 잘 입증되었습니다. 2014~15년에는 이를 비밀번호를 저장하는 Vault의 백엔드로 사용했습니다.

데이터가 손실되지 않음. Consul을 사용하는 동안 단 한 번의 사고에도 데이터가 손실되지 않았습니다. 이는 방화벽 관리 시스템에 있어서 큰 장점입니다.

P2P 연결로 변화 확산 가속화. P2P를 사용하면 모든 변경 사항이 빠르게 적용되므로 몇 시간씩 기다릴 필요가 없습니다.

편리한 REST API. Apache ZooKeeper도 고려했지만 REST API가 없으므로 목발을 설치해야 합니다.

KV(Key Vault) 및 디렉터리(서비스 검색)로 작동합니다.. 서비스, ​​카탈로그, 데이터센터를 한 번에 저장할 수 있습니다. 이는 우리뿐만 아니라 이웃 팀에게도 편리합니다. 글로벌 서비스를 구축할 때 우리는 크게 생각하기 때문입니다.

Wargaming 스택의 일부인 Go로 작성되었습니다. 우리는 이 언어를 좋아하고 Go 개발자도 많습니다.

강력한 ACL 시스템. Consul에서는 ACL을 사용하여 누가 무엇을 작성하는지 제어할 수 있습니다. 우리는 방화벽 규칙이 다른 규칙과 중복되지 않으며 이로 인해 문제가 발생하지 않을 것임을 보장합니다.

그러나 Consul에는 단점도 있습니다.

• 비즈니스 버전이 없으면 데이터 센터 내에서 확장되지 않습니다. 페더레이션을 통해서만 확장 가능합니다.
• 네트워크 품질과 서버 부하에 따라 크게 달라집니다. Consul은 속도가 고르지 않은 등 네트워크에 지연이 있는 경우 사용량이 많은 서버에서 서버로 제대로 작동하지 않습니다. 이는 P2P 연결 및 업데이트 배포 모델 때문입니다.
• 가용성 모니터링의 어려움. 영사 신분에서는 모든 것이 괜찮다고 말할 수 있지만 오래 전에 사망했습니다.

우리는 Consul을 사용하면서 이러한 문제를 대부분 해결했고 이것이 바로 우리가 Consul을 선택한 이유입니다. 회사는 대체 백엔드에 대한 계획을 가지고 있지만 문제를 처리하는 방법을 배웠으며 현재 Consul과 함께 생활하고 있습니다.

Consul의 작동 방식

조건부 데이터 센터에 XNUMX~XNUMX개의 서버를 설치할 예정입니다. 한두 대의 서버는 작동하지 않습니다. 데이터가 일치하지 않으면 정족수를 구성하고 누가 옳고 그른지 결정할 수 없습니다. XNUMX개 이상은 의미가 없으며 생산성이 떨어집니다.

클라이언트는 순서에 관계없이 서버에 연결합니다. 동일한 에이전트, 플래그만 사용 server = false.

그 후 클라이언트는 P2P 연결 목록을 수신하고 서로 연결을 구축합니다.

글로벌 수준에서는 여러 데이터 센터를 연결합니다. 또한 P2P를 연결하여 통신합니다.

다른 데이터 센터에서 데이터를 검색하려는 경우 요청은 서버에서 서버로 이동합니다. 이 계획은 농노 프로토콜. Consul과 마찬가지로 Serf 프로토콜은 HashiCorp에서 개발되었습니다.

Consul에 대한 몇 가지 중요한 사실

Consul에는 작동 방식을 설명하는 문서가 있습니다. 나는 알 가치가 있는 엄선된 사실들만을 제공할 것입니다.

Consul 서버는 유권자 중에서 마스터를 선택합니다.. Consul은 각 데이터 센터의 서버 목록에서 마스터를 선택하고 모든 요청은 서버 수에 관계없이 마스터로만 전달됩니다. 마스터 동결은 재선으로 이어지지 않습니다. 마스터를 선택하지 않으면 누구도 요청을 처리할 수 없습니다.

수평적 확장을 원하셨나요? 죄송합니다. 아니요.

다른 데이터 센터에 대한 요청은 어느 서버로 왔는지에 관계없이 마스터에서 마스터로 전달됩니다. 선택한 마스터는 전달 요청에 대한 로드를 제외하고 로드의 100%를 받습니다. 데이터 센터의 모든 서버에는 최신 데이터 복사본이 있지만 하나만 응답합니다.

확장하는 유일한 방법은 클라이언트에서 부실 모드를 활성화하는 것입니다.

부실 모드에서는 쿼럼 없이 응답할 수 있습니다. 이는 데이터 일관성을 포기하지만 평소보다 조금 더 빠르게 읽고 모든 서버가 응답하는 모드입니다. 당연히 마스터를 통해서만 녹음됩니다.

Consul은 데이터 센터 간에 데이터를 복사하지 않습니다.. 연합이 구성되면 각 서버는 자신의 데이터만 갖게 됩니다. 다른 사람들에게는 항상 다른 사람에게 의지합니다.

트랜잭션 외부에서는 작업의 원자성이 보장되지 않습니다.. 상황을 바꿀 수 있는 사람은 당신뿐만이 아니라는 점을 기억하십시오. 다르게 원한다면 잠금을 사용하여 트랜잭션을 수행하십시오.

차단 작업은 잠금을 보장하지 않습니다.. 요청은 직접이 아닌 마스터에서 마스터로 이동하므로 예를 들어 다른 데이터 센터에서 차단할 때 차단이 작동한다는 보장은 없습니다.

ACL은 또한 액세스를 보장하지 않습니다(대부분의 경우).. ACL은 하나의 페더레이션 데이터 센터, 즉 ACL 데이터 센터(기본 DC)에 저장되어 있으므로 작동하지 않을 수 있습니다. DC가 응답하지 않으면 ACL이 작동하지 않습니다.

하나의 동결된 마스터로 인해 전체 연합이 동결됩니다.. 예를 들어, 페더레이션에는 10개의 데이터 센터가 있는데 그 중 하나는 네트워크 상태가 좋지 않고 하나는 마스터에 장애가 발생합니다. 그와 대화하는 모든 사람은 원 안에 갇힐 것입니다. 요청이 있지만 응답이 없으며 스레드가 정지됩니다. 언제 이런 일이 일어날지 알 수 있는 방법이 없습니다. 한두 시간만 지나면 연방 전체가 무너질 것입니다. 당신이 할 수 있는 일은 아무것도 없습니다.

상태, 정족수 및 선택은 별도의 스레드에서 처리됩니다. 재선거는 발생하지 않으며 상태에는 아무 것도 표시되지 않습니다. 당신은 살아있는 영사가 있다고 생각하고 물어봐도 아무 일도 일어나지 않습니다. 대답이 없습니다. 동시에 상태는 모든 것이 정상임을 나타냅니다.

우리는 이 문제에 직면했고 이를 피하기 위해 데이터 센터의 특정 부분을 재구축해야 했습니다.

Consul Enterprise의 비즈니스 버전에는 위의 단점 중 일부가 없습니다.. 유권자 선택, 배포, 규모 조정 등 유용한 기능이 많이 있습니다. "그러나"는 단 하나뿐입니다. 분산 시스템의 라이센스 시스템은 매우 비쌉니다.

생명 해킹 : rm -rf /var/lib/consul - 대리인의 모든 질병에 대한 치료법. 문제가 해결되지 않으면 데이터를 삭제하고 복사본에서 데이터를 다운로드하세요. 아마도 영사가 일할 것입니다.

이전

이제 Consul에 추가한 내용에 대해 이야기해 보겠습니다.

이전 의 약어이다 B응답EndF분노W모두. 첫 번째 테스트 커밋을 저장소에 넣기 위해 저장소를 만들 때 어떻게든 제품 이름을 지정해야 했습니다. 이 이름이 남아있습니다.

규칙 템플릿

규칙은 iptables 구문으로 작성됩니다.

• -N 이전
• -P 입력 드롭
• -A 입력 -m 상태 - 관련됨, 설정됨 상태 -j 수락
• -A 입력 -i lo -j 수락
• -A 입력 -j BEFW

다음을 제외한 모든 것이 BEFW 체인으로 들어갑니다. ESTABLISHED, RELATED 그리고 로컬호스트. 템플릿은 무엇이든 될 수 있습니다. 이는 단지 예일 뿐입니다.

BEFW는 어떻게 유용합니까?

서비스

우리에게는 서비스가 있으며 항상 포트, 즉 실행되는 노드가 있습니다. 우리 노드에서 로컬로 에이전트에게 물어보고 어떤 종류의 서비스가 있는지 알아볼 수 있습니다. 태그를 넣을 수도 있습니다.

Consul에 실행되고 등록된 모든 서비스는 iptables 규칙으로 전환됩니다. 우리는 SSH를 가지고 있습니다 - 열린 포트 22. Bash 스크립트는 간단합니다: 컬과 iptables, 다른 것은 필요하지 않습니다.

클라이언트

모든 사람이 아닌 선택적으로 액세스를 여는 방법은 무엇입니까? 서비스 이름으로 KV 스토리지에 IP 목록을 추가합니다.

예를 들어, 우리는 22번째 네트워크의 모든 사람이 SSH_TCP_XNUMX 서비스에 액세스할 수 있기를 원합니다. 하나의 작은 TTL 필드를 추가하시겠습니까? 이제 우리는 예를 들어 하루 동안의 임시 허가를 받았습니다.

액세스

우리는 서비스와 클라이언트를 연결합니다. 우리에게는 서비스가 있으며 KV 스토리지는 각각에 대해 준비되어 있습니다. 이제 우리는 모든 사람에게 액세스 권한을 부여하는 것이 아니라 선택적으로 액세스 권한을 부여합니다.

그룹

매번 액세스를 위해 수천 개의 IP를 작성한다면 우리는 피곤해질 것입니다. KV의 별도 하위 집합인 그룹화를 생각해 보겠습니다. 이를 별칭(또는 그룹)이라고 부르고 동일한 원리에 따라 거기에 그룹을 저장해 보겠습니다.

연결해 보겠습니다. 이제 특별히 P2P용이 아닌 전체 그룹 또는 여러 그룹에 대해 SSH를 열 수 있습니다. 같은 방식으로 TTL이 있습니다. 그룹에 추가하고 일시적으로 그룹에서 제거할 수 있습니다.

Интеграция

우리의 문제는 인적 요소와 자동화입니다. 지금까지는 이 방법으로 해결했습니다.

우리는 Puppet과 협력하여 시스템(애플리케이션 코드)과 관련된 모든 것을 Puppet에 전송합니다. Puppetdb(일반 PostgreSQL)는 그곳에서 실행 중인 서비스 목록을 저장하며 리소스 유형별로 찾을 수 있습니다. 누가 어디에 지원하는지 확인할 수 있습니다. 이를 위한 풀 요청 및 병합 요청 시스템도 있습니다.

우리는 데이터 전송을 돕는 간단한 솔루션인 befw-sync를 작성했습니다. 첫째, 동기화 쿠키는 puppetdb를 통해 액세스됩니다. HTTP API가 구성되어 있습니다. 우리는 어떤 서비스를 가지고 있는지, 무엇을 해야 하는지 요청합니다. 그런 다음 그들은 영사에게 요청합니다.

통합이 있나요? 그렇습니다. 그들은 규칙을 작성하고 Pull Request가 허용되도록 허용했습니다. 특정 포트가 필요합니까, 아니면 일부 그룹에 호스트를 추가합니까? 끌어오기 요청, 검토 - 더 이상 "200개의 다른 ACL을 찾아 이에 대해 조치를 취해보세요."

최적화

빈 규칙 체인을 사용하여 localhost를 핑하는 데 0,075ms가 걸립니다.

이 체인에 10개의 iptables 주소를 추가해 보겠습니다. 결과적으로 핑은 000배 증가합니다. iptables는 완전히 선형이므로 각 주소를 처리하는 데 약간의 시간이 걸립니다.

수천 개의 ACL을 마이그레이션하는 방화벽의 경우 많은 규칙이 있으며 이로 인해 대기 시간이 발생합니다. 이는 게임 프로토콜에 좋지 않습니다.

하지만 우리가 넣으면 IPset의 주소 10개 핑도 감소합니다.

요점은 규칙이 아무리 많아도 ipset의 "O"(알고리즘 복잡도)는 항상 1과 같다는 것입니다. 사실, 제한이 있습니다 - 규칙은 65535개를 넘을 수 없습니다. 현재 우리는 이것을 결합하고 확장하고 두 개의 IPset을 하나로 만들 수 있습니다.

저장

반복 프로세스의 논리적 연속은 서비스에 대한 클라이언트 정보를 ipset에 저장하는 것입니다.

이제 우리는 동일한 SSH를 가지고 있으며 한 번에 100개의 IP를 쓰지 않고 통신해야 하는 IPset의 이름을 설정하고 다음 규칙을 설정합니다. DROP. '누가 여기 없나, DROP'라는 하나의 규칙으로 변환할 수도 있지만 더 명확합니다.

이제 규칙과 세트가 생겼습니다. 주요 작업은 규칙을 작성하기 전에 세트를 만드는 것입니다. 그렇지 않으면 iptables가 규칙을 작성하지 않기 때문입니다.

일반 계획

다이어그램 형태로 말하면 내가 말한 모든 내용은 다음과 같습니다.

우리는 Puppet을 약속하며, 모든 것이 호스트로 전송되고, 서비스는 여기, IPset은 거기에 등록되지 않은 사람은 허용되지 않습니다.

거부 허용

신속하게 세상을 구하거나 누군가를 신속하게 비활성화하기 위해 모든 체인의 시작 부분에 두 개의 ipset을 만들었습니다. rules_allow и rules_deny. 어떻게 작동합니까?

예를 들어, 누군가가 봇을 사용하여 웹에 부하를 생성하고 있습니다. 이전에는 트래픽 소스를 찾아 그를 차단할 수 있도록 로그에서 그의 IP를 찾아 네트워크 엔지니어에게 전달해야 했습니다. 지금은 달라 보입니다.

Consul에게 보내고 2,5초 기다리면 완료됩니다. Consul은 P2P를 통해 빠르게 배포하기 때문에 세계 어느 곳에서나 작동합니다.

방화벽 실수로 인해 어떻게 든 WOT를 완전히 중지했습니다. rules_allow - 이는 그러한 경우에 대비한 당사의 보험입니다. 방화벽 어딘가에서 실수를 해서 어딘가에서 무언가가 차단된 경우 언제든지 조건부 메시지를 보낼 수 있습니다. 0.0/0빨리 모든 것을 집어 들기 위해. 나중에 우리는 모든 것을 손으로 고칠 것입니다.

기타 세트

공간에 다른 세트를 추가할 수 있습니다. $IPSETS$.

무엇을 위해? 예를 들어 클러스터 일부의 종료를 에뮬레이트하기 위해 누군가 ipset이 필요한 경우가 있습니다. 누구나 세트를 가져와서 이름을 지정하면 영사가 픽업해 드립니다. 동시에 세트는 iptables 규칙에 참여하거나 팀으로 활동할 수 있습니다. NOOP: 일관성은 데몬에 의해 유지됩니다.

회원

이전에는 사용자가 네트워크에 연결하고 도메인을 통해 매개변수를 받는 방식이었습니다. 차세대 방화벽이 등장하기 전에 Cisco는 사용자가 어디에 있는지, IP가 어디에 있는지 파악하는 방법을 몰랐습니다. 따라서 머신의 호스트 이름을 통해서만 액세스가 허용되었습니다.

우리는 무엇을 했나요? 주소를 받는 순간 막혔습니다. 일반적으로 이는 dot1x, Wi-Fi 또는 VPN이며 모든 것이 RADIUS를 통과합니다. 각 사용자에 대해 사용자 이름으로 그룹을 생성하고 dhcp.lease와 동일한 TTL을 사용하여 그룹에 IP를 배치합니다. 만료되자마자 규칙은 사라집니다.

이제 다른 그룹과 마찬가지로 사용자 이름으로 서비스에 대한 액세스를 열 수 있습니다. 우리는 호스트 이름이 변경될 때 발생하는 어려움을 없애고 더 이상 Cisco가 필요하지 않기 때문에 네트워크 엔지니어의 부담을 덜어주었습니다. 이제 엔지니어가 직접 서버에 액세스를 등록합니다.

절연

동시에 우리는 단열재를 해체하기 시작했습니다. 서비스 관리자는 인벤토리를 조사하고 모든 네트워크를 분석했습니다. 이를 동일한 그룹으로 나누고 필요한 서버에 예를 들어 거부를 위해 그룹을 추가해 보겠습니다. 이제 동일한 스테이징 격리가 프로덕션의 rule_deny에서 끝나지만 프로덕션 자체에서는 그렇지 않습니다.

이 체계는 빠르고 간단하게 작동합니다. 서버에서 모든 ACL을 제거하고, 하드웨어를 언로드하고, 격리된 VLAN의 수를 줄입니다.

무결성 관리

이전에는 누군가 방화벽 규칙을 수동으로 변경했을 때 이를 보고하는 특수 트리거가 있었습니다. 방화벽 규칙을 확인하기 위해 거대한 린터를 작성하고 있었는데 어려웠습니다. 무결성은 이제 BEFW에 의해 제어됩니다. 그는 자신이 정한 규칙이 변경되지 않도록 열심히 노력합니다. 누군가 방화벽 규칙을 변경하면 모든 것이 다시 변경됩니다. “집에서 일할 수 있도록 신속하게 프록시를 설정했습니다.”—그런 옵션은 더 이상 없습니다.

BEFW는 BEFW 체인의 서비스 규칙인 befw.conf의 서비스 및 목록에서 IPset을 제어합니다. 하지만 다른 체인과 규칙, 다른 IPset은 모니터링하지 않습니다.

충돌 방지

BEFW는 항상 마지막으로 알려진 양호한 상태를 state.bin 바이너리 구조에 직접 저장합니다. 문제가 발생하면 항상 이 state.bin으로 롤백됩니다.

이는 데이터를 전송하지 않았거나 누군가 실수를 하여 적용할 수 없는 규칙을 사용한 불안정한 영사 운영에 대한 보험입니다. 방화벽 없이 방치되지 않도록 BEFW는 어떤 단계에서든 오류가 발생하면 최신 상태로 롤백합니다.

중요한 상황에서는 방화벽이 작동하게 된다는 보장이 있습니다. 관리자가 와서 문제를 해결할 것이라는 희망으로 모든 회색 네트워크를 엽니다. 언젠가는 이것을 구성에 넣을 것이지만 지금은 10/8, 172/12 및 192.168/16의 세 가지 회색 네트워크만 있습니다. 영사 내에서 이는 우리가 더욱 발전하는 데 도움이 되는 중요한 기능입니다.

데모: 보고서가 진행되는 동안 Ivan은 BEFW의 데모 모드를 시연합니다. 시연을 보는 것이 더 쉽습니다. 비디오. 데모 소스 코드 사용 가능 GitHub에서.

주의

발생한 버그에 대해 말씀드리겠습니다.

ipset 추가 세트 0.0.0.0/0. ipset에 0.0.0.0/0을 추가하면 어떻게 되나요? 모든 IP가 추가되나요? 인터넷 접속이 가능합니까?

아니요, 2016시간의 가동 중지 시간을 초래하는 버그가 발생하게 됩니다. 게다가 이 버그는 1297092년 이후로 작동하지 않았습니다. 이 버그는 RedHat Bugzilla의 번호 #XNUMX에 있으며 개발자 보고서에서 우연히 발견했습니다.

이제 BEFW에서는 다음과 같은 엄격한 규칙이 적용되었습니다. 0.0.0.0/0 두 개의 주소로 변환됩니다. 0.0.0.0/1 и 128.0.0.0/1.

ipset 복원 세트 < 파일. ipset에 지시하면 무엇을 합니까? restore? iptables와 동일하게 작동한다고 생각하시나요? 데이터를 복구할 수 있나요?

그런 것은 없습니다. 병합을 수행하고 이전 주소는 아무데도 가지 않으며 액세스를 차단하지 않습니다.

격리를 테스트하는 동안 버그를 발견했습니다. 이제 다소 복잡한 시스템이 있습니다. restore 개최 create temp, 그 다음에 restore flush temp и restore temp. 스왑이 끝나면 원자성을 위해 먼저 수행하면 됩니다. flush 이 순간 일부 패킷이 도착하면 폐기되고 문제가 발생합니다. 그래서 거기에는 약간의 흑마법이 있습니다.

consul kv get -datacenter=other. 내가 말했듯이 우리는 데이터를 요청한다고 생각하지만 데이터를 얻거나 오류가 발생합니다. 로컬에서 Consul을 통해 이 작업을 수행할 수 있지만 이 경우 둘 다 정지됩니다.

로컬 Consul 클라이언트는 HTTP API에 대한 래퍼입니다. 하지만 그냥 멈추고 Ctrl+C나 Ctrl+Z 등 ​​어떤 것에도 응답하지 않습니다. kill -9 다음 콘솔에서. 대규모 클러스터를 구축할 때 이런 문제가 발생했습니다. 하지만 아직 해결 방법이 없어 Consul에서 이 오류를 수정할 준비를 하고 있습니다.

영사 지도자가 응답하지 않습니다. 데이터 센터의 마스터가 응답하지 않습니다. "아마도 이제 재선택 알고리즘이 작동할까요?"라고 생각합니다.

아니요, 작동하지 않으며 모니터링에는 아무 것도 표시되지 않습니다. Consul은 헌신 지수가 있고 리더가 발견되었으며 모든 것이 괜찮다고 말할 것입니다.

우리는 이것을 어떻게 처리합니까? service consul restart 매 시간마다 cron에 표시됩니다. 서버가 50개라면 별 문제가 되지 않습니다. 16개가 있으면 그것이 어떻게 작동하는지 이해하게 될 것입니다.

결론

그 결과 우리는 다음과 같은 이점을 얻었습니다.

• 모든 Linux 시스템을 100% 지원합니다.
• 속도
• 오토메이션.
• 우리는 하드웨어 및 네트워크 엔지니어를 노예 생활에서 해방시켰습니다.
• 거의 무한한 통합 가능성이 나타났습니다. Kubernetes, Ansible, Python에서도 마찬가지입니다.

죄수 팀은: 이제 우리가 함께 살아야 하는 영사, 그리고 매우 높은 오류 비용. 예를 들어, 오후 6시(러시아 최고의 시간대)에 저는 네트워크 목록에서 무언가를 편집하고 있었습니다. 당시 우리는 BEFW에서 단열재를 만들고 있었습니다. 어딘가에서 실수를 해서 마스크를 잘못 표시한 것 같은데 모든 것이 XNUMX초 만에 끝났습니다. 모니터링이 켜지고 담당 지원 담당자가 달려옵니다. "우리는 모든 것을 갖추고 있습니다!" 부서장은 왜 이런 일이 일어났는지 사업부에 설명하자 얼굴이 어두워졌습니다.

오류로 인해 발생하는 비용이 너무 높기 때문에 자체적으로 복잡한 예방 절차를 마련했습니다. 대규모 프로덕션 사이트에서 이를 구현하는 경우 Consul을 통해 모든 사람에게 마스터 토큰을 제공할 필요가 없습니다. 이것은 나쁘게 끝날 것입니다.

비용. 혼자서 400시간 동안 코드를 작성했습니다. 4명으로 구성된 저희 팀은 모든 사람을 지원하기 위해 한 달에 10시간을 보냅니다. 차세대 방화벽의 가격과 비교하면 무료입니다.

계획. 장기 계획은 Consul을 대체하거나 보완할 대체 교통 수단을 찾는 것입니다. 아마도 Kafka나 그와 유사한 것이 될 것입니다. 하지만 앞으로 몇 년 안에 우리는 Consul을 사용하게 될 것입니다.

즉각적인 계획: Fail2ban, 모니터링, nftables, 다른 배포판, 지표, 고급 모니터링, 최적화와의 통합. Kubernetes 지원도 계획 어딘가에 포함되어 있습니다. 이제 여러 클러스터가 있고 원하는 바가 있기 때문입니다.

더 많은 계획:

• 교통의 이상 징후를 검색합니다.
• 네트워크 맵 관리;
• 쿠버네티스 지원;
• 모든 시스템에 대한 패키지 조립;
• 웹-UI.

우리는 지속적으로 구성을 확장하고 측정항목과 최적화를 늘리기 위해 노력하고 있습니다.

프로젝트에 참여하세요. 결과적으로는 멋진 프로젝트였지만, 아쉽게도 여전히 XNUMX인 프로젝트입니다. 오다 GitHub의 그리고 뭔가를 해보세요. 커밋하고, 테스트하고, 제안하고, 평가해 보세요.

그 사이에 우리는 준비 중이야 세인트 하이로드++6월 7일과 XNUMX일 상트페테르부르크에서 개최되며 고부하 시스템 개발자를 초대합니다. 보고서를 신청하다. 숙련된 연사들은 이미 무엇을 해야 할지 알고 있지만, 말하기를 처음 접하는 사람들에게는 최소한 다음을 권장합니다. 시도하다. 컨퍼런스에 연사로 참여하면 여러 가지 이점이 있습니다. 예를 들어 마지막에 어떤 내용이 있는지 읽을 수 있습니다. 이 기사.

출처 : habr.com