내 미완성 프로젝트. 200개의 MikroTik 라우터 네트워크

안녕하세요 여러분. 이 글은 여러 대의 Mikrotik 장치를 보유하고 있으며, 각 장치에 별도로 연결하지 않고도 최대한의 통합을 이루고자 하는 분들을 위해 작성되었습니다. 이 글에서는 불행히도 인적 요인으로 인해 전투 상황에 도달하지 못한 프로젝트에 대해 설명하겠습니다. 간단히 말해서, 200개가 넘는 라우터, 빠른 설정 및 직원 교육, 지역별 통합, 네트워크 및 특정 호스트 필터링, 모든 장치에 규칙을 쉽게 추가하는 기능, 로깅 및 액세스 제어 기능이 있습니다.

아래에 설명된 내용은 기성 사례라고 주장하는 것은 아니지만, 네트워크를 계획하고 오류를 최소화하는 데 도움이 되기를 바랍니다. 어쩌면 일부 요점과 해결책이 여러분에게 옳지 않다고 생각될 수도 있습니다. 그렇다면 댓글로 남겨주세요. 이 경우 비판은 공동의 이익을 위한 경험이 될 것입니다. 그러니 독자 여러분, 댓글을 살펴보세요. 작성자가 큰 실수를 했을 수도 있습니다. 커뮤니티가 도와줄 것입니다.

라우터의 수는 200~300개이며, 인터넷 연결 품질이 서로 다른 여러 도시에 분산되어 있습니다. 모든 것을 아름답게 만들어야 하며, 모든 것이 어떻게 작동할지 지역 관리자에게 명확하게 설명해야 합니다.

그렇다면 프로젝트는 어디서 시작해야 할까요? 물론, TK.

1. 고객 요구 사항에 따라 모든 지점에 대한 네트워크 계획을 구성하고 네트워크를 세분화합니다(지점당 장치 수에 따라 3개에서 20개 네트워크).
2. 각 지점에 장치를 설정합니다. 다양한 운영 조건에서 공급자의 실제 대역폭 속도를 확인합니다.
3. 기기 보호 조직, 허용 목록 관리, 일정 기간 동안 자동 블랙리스트에 등록하여 공격을 자동 감지하고, 접근을 가로채고 제어하며 서비스를 거부하는 데 사용되는 다양한 기술적 수단의 사용을 최소화합니다.
4. 고객 요구 사항에 따라 네트워크 필터링을 통해 안전한 VPN 연결을 구성합니다. 각 지점에서 센터로 가는 VPN 연결은 최소 3개입니다.
5. 1, 2번 항목을 바탕으로 장애 허용형 VPN을 구축하는 최적의 방법을 선택하세요. 공연자는 올바른 이유로 동적 라우팅 기술을 선택할 수 있습니다.
6. 고객이 사용하는 프로토콜, 포트, 호스트 및 기타 특정 서비스별로 트래픽 우선순위를 구성합니다. (VOIP, 중요 서비스를 제공하는 호스트)
7. 기술 지원 담당자의 대응을 위해 라우터 이벤트에 대한 모니터링과 로깅을 구성합니다.

우리가 아는 바에 따르면, 많은 경우 기술 사양은 요구 사항에 따라 결정됩니다. 저는 주요 문제들을 듣고 나서 이러한 요구사항을 직접 공식화했습니다. 저는 다른 사람이 이러한 사항의 구현을 맡을 가능성을 고려했습니다.

이러한 요구 사항을 충족하기 위해 어떤 도구가 사용될까요?

1. ELK 스택(얼마 후, Logstash 대신 fluentd를 사용하는 것이 분명해졌습니다).
2. 앤서블. 관리와 접근 공유의 편의성을 위해 AWX를 사용합니다.
3. 깃랩. 설명할 필요가 없습니다. 구성의 버전 제어가 없었다면 어떻게 되었을까요?
4. 파워셸. 구성을 처음 생성하기 위한 간단한 스크립트가 있습니다.
5. Doku 위키는 문서와 가이드를 작성하는 데 사용됩니다. 이 경우에는 habr.com을 사용합니다.
6. 모니터링은 Zabbix를 통해 수행됩니다. 일반적인 이해를 돕기 위해 연결 다이어그램도 그려져 있습니다.

EFK 설정 포인트

첫 번째 사항과 관련해서는 지수가 구축될 이념에 대해서만 설명하겠습니다. 많은 것들이 있습니다
mikrotik을 실행하는 장치에서 로그를 설정하고 수신하는 방법에 대한 훌륭한 문서입니다.

몇 가지 점에 대해 말씀드리겠습니다.

1. 이 계획에 따르면, 다양한 장소와 다양한 포트에서 로그를 수신하는 것을 고려해 볼 만합니다. 이를 위해 로그 집계기를 사용하겠습니다. 또한, 모든 라우터에 대한 액세스를 분리할 수 있는 범용 그래프를 만들고 싶습니다. 그러면 다음과 같이 인덱스를 구성합니다.

fluentd를 사용한 구성은 다음과 같습니다. 엘라스틱서치 타입
로그스태시_포맷 참
인덱스 이름 mikrotiklogs.north
logstash_prefix mikrotiklogs.north
플러시 간격 10초
호스트 탄성 검색: 9200
포트 9200

이런 방식으로 우리는 라우터를 결합하고 mikrotiklogs.west, mikrotiklogs.south, mikrotiklogs.east와 같은 계획에 따라 세분화할 수 있습니다. 왜 이렇게 복잡하게 만들었을까? 우리는 200개 이상의 장치를 보유하게 될 것으로 알고 있습니다. 모든 것을 기억하는 것은 불가능합니다. Elasticsearch 6.8 버전부터는 라이선스를 구매하지 않고도 보안 설정에 접근할 수 있으므로 기술 지원 담당자나 로컬 시스템 관리자에게 보기 권한을 분배할 수 있습니다.
표와 그래프 - 이 경우에는 서로 합의만 하면 됩니다 - 같은 것을 사용하거나 각자가 가장 편리한 방법을 사용하면 됩니다.

2. 로깅에 관하여. 방화벽 규칙에서 로깅을 활성화하면 이름에 공백이 없어집니다. fluentd에서 간단한 구성을 사용하면 데이터를 필터링하고 편리한 패널을 만들 수 있다는 것은 분명합니다. 아래 그림은 내 집 라우터를 보여줍니다.

3. 점유된 공간과 통나무로. 평균적으로 시간당 1000개의 메시지가 처리되므로 로그는 하루에 2~3MB를 차지합니다. 이는 그렇게 많지 않다는 것을 인정해야 합니다. Elasticsearch 버전 7.5.

ANSIBLE.AWX

다행히도 우리에게는 라우터용 기성 모듈이 있습니다.
저는 AWX를 지정했지만, 아래 명령은 순수한 형태의 Ansible에 대한 것일 뿐입니다. Ansible을 사용해 본 사람이라면 GUI를 통해 AwX를 사용하는 데 아무런 문제가 없을 것이라고 생각합니다.

솔직히 말해서, 이전에 ssh를 사용한 다른 가이드를 살펴봤는데, 모두 응답 시간 문제와 그 외 여러 가지 다른 문제를 겪고 있었습니다. 다시 말씀드리지만, 싸움으로 이어지지는 않았습니다.  이 정보는 20대의 라우터를 넘어서지 않는 실험으로 받아들여주세요.

인증서나 계정을 사용해야 합니다. 결정은 당신에게 달려 있습니다. 저는 자격증을 지지합니다. 권리에 대한 미묘한 점. 쓰기 권한을 줬는데 "구성 재설정"도 작동하지 않아요.

인증서 생성, 복사 및 가져오기에는 문제가 없습니다.

명령어의 간략한 목록귀하의 PC에서
ssh-keygen -t RSA, 질문에 답하고 키를 저장합니다.
mikrotik에 복사:
사용자 ssh-키 가져오기 public-key-file=id_mtx.pub 사용자=ansible
먼저, 계정을 만들고 권한을 할당해야 합니다.
인증서를 사용하여 연결 확인
ssh -p 49475 -i /keys/mtx ansible@192.168.0.120

vi /etc/ansible/hosts를 작성합니다.
MT01 ansible_network_os=라우터 ansible_ssh_port=49475 ansible_ssh_user= ansible
MT02 ansible_network_os=라우터 ansible_ssh_port=49475 ansible_ssh_user= ansible
MT03 ansible_network_os=라우터 ansible_ssh_port=49475 ansible_ssh_user= ansible
MT04 ansible_network_os=라우터 ansible_ssh_port=49475 ansible_ssh_user= ansible

음, 플레이북의 예는 다음과 같습니다. — 이름: add_work_sites
호스트: testmt
시리얼: 1
연결: network_cli
remote_user: mikrotik.west
gather_facts: 예
작업 :
— 이름: 작업 사이트 추가
경로 명령:
명령 :
— /ip 방화벽 주소 목록 추가 주소=gov.ru 목록=work_sites 주석=Ticket665436_Ochen_nado
— /ip 방화벽 주소 목록 추가 주소=habr.com 목록=work_sites 주석=for_habr

위의 구성에서 볼 수 있듯이, 자신의 플레이북을 만드는 것은 어렵지 않습니다. 클리 미크로틱을 잘 다루면 충분합니다. 모든 라우터에서 특정 데이터가 포함된 주소 목록을 제거해야 하는 상황을 상상해 보겠습니다. 그러면:

찾아서 삭제/ip 방화벽 주소 목록 제거 [find where list="gov.ru"]

여기에 전체 방화벽 목록을 의도적으로 넣지 않은 이유는... 각 프로젝트마다 개별적이기 때문입니다. 하지만 확실히 말할 수 있는 건 주소 목록만 사용하라는 겁니다.

GITLAB에 대한 모든 것은 명확합니다. 이 점에 대해서는 더 이상 언급하지 않겠습니다. 모든 것은 별도의 작업, 템플릿, 핸들러에서 아름답습니다.

파워 쉘

여기에는 3개의 파일이 있습니다. 왜 PowerShell을 사용해야 하나요? 귀하에게 더 편리한 도구를 선택하여 구성을 생성할 수 있습니다. 이 경우 모든 사람의 PC에 Windows가 설치되어 있으므로 PowerShell이 ​​더 편리할 때 Bash에서 작업할 필요가 없습니다. 귀하에게 더 편리한 것이라면.

스크립트 자체(간단하고 명확함):[cmdletBinding()]
매개변수(
[매개변수(필수=$true)]
[문자열]$외부지침,
[매개변수(필수=$true)]
[문자열]$EXTERNALIPROUTE,
[매개변수(필수=$true)]
[문자열]$BWorknets,
[매개변수(필수=$true)]
[문자열]$CWorknets,
[매개변수(필수=$true)]
[문자열]$BVoipNets,
[매개변수(필수=$true)]
[문자열]$CVoipNets,
[매개변수(필수=$true)]
[문자열]$CClientss,
[매개변수(필수=$true)]
[문자열]$BVPNWORKS,
[매개변수(필수=$true)]
[문자열]$CVPNWORKS,
[매개변수(필수=$true)]
[문자열]$BVPNCLIENTSs,
[매개변수(필수=$true)]
[문자열]$cVPNCLIENTSs,
[매개변수(필수=$true)]
[문자열]$NAMEROUTER,
[매개변수(필수=$true)]
[string]$ServerCertificates,
[매개변수(필수=$true)]
[문자열]$infile,
[매개변수(필수=$true)]
[문자열]$outfile
)

Get-Content $infile | Foreach-Object {$_.Replace("EXTERNIP", $EXTERNALIPADDRESS)} |
Foreach 객체 {$_.Replace("EXTROUTE", $EXTERNALIPROUTE)} |
Foreach-Object {$_.Replace("BWorknet", $BWorknets)} |
Foreach-Object {$_.Replace("CWorknet", $CWorknets)} |
Foreach 객체 {$_.Replace("BVoipNet", $BVoipNets)} |
Foreach 객체 {$_.Replace("CVoipNet", $CVoipNets)} |
Foreach-객체 {$_.Replace("CClients", $CClientss)} |
Foreach 객체 {$_.Replace("BVPNWORK", $BVPNWORKs)} |
Foreach 객체 {$_.Replace("CVPNWORK", $CVPNWORKs)} |
Foreach 객체 {$_.Replace("BVPNCLIENTS", $BVPNCLIENTSs)} |
Foreach 객체 {$_.Replace("CVPNCLIENTS", $cVPNCLIENTSs)} |
Foreach 객체 {$_.Replace("MYNAMERROUTER", $NAMEROUTER)} |
Foreach-Object {$_.Replace("ServerCertificate", $ServerCertificates)} | Set-Content $outfile

용서해 주세요. 모든 규칙을 게시할 수는 없어요... 별로 보기 좋지 않을 테니까요. 모범 사례에 따라 직접 규칙을 만들 수 있습니다.

예를 들어, 내가 팔로우한 링크 목록은 다음과 같습니다.wiki.mikrotik.com/wiki/Manual:라우터 보안
wiki.mikrotik.com/wiki/Manual:IP/방화벽/필터
wiki.mikrotik.com/wiki/Manual:OSPF 예제
wiki.mikrotik.com/wiki/Drop_port_scanners
wiki.mikrotik.com/wiki/Manual:윈박스
wiki.mikrotik.com/wiki/Manual:라우터OS 업그레이드
wiki.mikrotik.com/wiki/Manual:IP/Fasttrack — 여기서 알아야 할 점은 Fasttrack이 활성화되면 우선순위 지정 및 트래픽 조정 규칙이 작동하지 않는다는 것입니다. 이는 성능이 약한 장치에 유용합니다.

변수에 대한 기존 표기법:다음 네트워크를 예로 들어 보겠습니다.
192.168.0.0/24 작동 네트워크
172.22.4.0/24 VOIP 네트워크
로컬 네트워크에 액세스할 수 없는 클라이언트를 위한 10.0.0.0/24 네트워크
대규모 지점을 위한 192.168.255.0/24 VPN 네트워크
소규모 기업을 위한 172.19.255.0/24 VPN 네트워크

네트워크 주소는 4개의 192.168.0.0진수 ABCD로 구성되어 있으며, 대체는 동일한 원리로 작동합니다. 시작 시 B를 묻는 경우 네트워크 24/0에 대해 숫자 0을 입력해야 하고, C에는 XNUMX을 입력해야 함을 의미합니다.
$EXTERNALIPADDRESS — 공급자의 전용 주소입니다.
$EXTERNALIPROUTE — 네트워크 0.0.0.0/0에 대한 기본 경로
$BWorknets — Worknet, 우리 예에서는 168이 됩니다.
$CWorknets — 작업 네트워크, 우리 예에서는 0이 됩니다.
$BVoipNets — 여기 예시의 VOIP 네트워크 22
$CVoipNets — 여기 예시의 VOIP 네트워크 4
$CClientss — 클라이언트용 네트워크 – 인터넷에만 액세스 가능, 이 경우에는 0입니다.
$BVPNWORKs — 대규모 지점을 위한 VPN 네트워크(예: 20)
$CVPNWORKs — 대규모 지점을 위한 VPN 네트워크(예: 255)
$BVPNCLIENTS — 소규모 지점을 위한 VPN 네트워크, 19
$CVPNCLIENTS — 소규모 지점을 위한 VPN 네트워크이므로 255
$NAMEROUTER — 라우터 이름
$ServerCertificate - 이전에 가져온 인증서의 이름
$infile — 구성을 읽을 파일의 경로를 지정합니다(예: D:config.txt(따옴표와 공백이 없는 영어 경로가 바람직함)).
$outfile — 저장할 경로를 지정합니다(예: D:MT-test.txt).

저는 명확한 이유로 예시에서 주소를 의도적으로 변경했습니다.

공격과 비정상적인 행동을 감지하는 것에 대한 요점을 놓쳤습니다. 이는 별도의 기사로 다루어야 할 것 같습니다. 하지만 이 카테고리에서는 Zabbix의 모니터링 데이터 값과 Elasticsearch의 처리된 curl 데이터를 사용할 수 있다는 점에 주목할 가치가 있습니다.

어떤 점에 집중해야 할까요?

1. 네트워크 계획. 바로 읽을 수 있는 형태로 작성하는 것이 좋습니다. 엑셀이면 충분합니다. 안타깝게도 저는 네트워크가 "새로운 지점이 생겼습니다. 여기에 /24가 있습니다."라는 원칙에 따라 만들어지는 것을 자주 봅니다. 이 지역에서 얼마나 많은 기기가 사용될 것으로 예상되는지, 그리고 앞으로도 계속 성장할지는 아무도 알 수 없습니다. 예를 들어, 작은 매장이 문을 열었는데, 처음에는 장치가 10을 넘지 않을 것이 분명했습니다. 왜 /24를 할당했습니까? 반면, 대규모 지점의 경우 /24가 할당되고, 장치가 500개이므로 간단히 네트워크를 추가할 수 있지만, 모든 것을 한 번에 생각해 보는 것이 좋습니다.
2. 필터링 규칙. 프로젝트에서 네트워크 분리와 최대 세분화가 이루어질 것이라고 가정합니다. 모범 사례는 시간이 지남에 따라 변합니다. 이전에는 PC 네트워크와 프린터 네트워크가 분리되었지만, 지금은 이러한 네트워크를 분리하지 않는 것이 매우 일반적입니다. 상식적으로 불필요한 곳에 여러 개의 서브넷을 만들지 않고 모든 장치를 하나의 네트워크로 결합하지 않는 것이 좋습니다.
3. 모든 라우터에 "골든" 설정 적용. 저것들. 만약 당신이 계획을 세웠다면. 모든 것을 바로 고려하고 모든 설정이 동일한지 확인하는 것이 좋습니다. 주소 목록과 IP 주소만 다릅니다. 문제가 발생할 경우 디버깅 시간이 단축됩니다.
4. 조직적인 측면은 기술적인 측면만큼 중요합니다. 게으른 직원은 기성 구성과 스크립트를 사용하지 않고 "수동으로" 권장 사항을 따르는 경우가 많은데, 이는 결국 예기치 못한 문제를 야기합니다.

동적 라우팅을 통해서. 구역 분할이 가능한 OSPF가 사용되었습니다. 하지만 이것은 시험대입니다. 이런 것들을 전투 상황에 맞춰 설정하는 게 더 흥미롭죠.

제가 라우터 구성을 게시하지 않아서 화가 난 사람이 없기를 바랍니다. 저는 링크만 있으면 충분하다고 생각하고, 그 외에는 요구 사항에 따라 달라집니다. 물론 테스트도 필요하고, 더 많은 테스트가 필요합니다.

새해에는 모두가 계획한 프로젝트를 실현하길 바랍니다. 접근 권한이 귀하와 함께 있기를 바랍니다!!!

출처 : habr.com