הפרויקט הלא ממומש שלי. רשת של 200 נתבי MikroTik

שלום לכולם. מאמר זה מיועד למי שיש בצי מכשירי מיקרוטיק רבים, ורוצים לבצע איחוד מירבי כדי לא להתחבר לכל מכשיר בנפרד. במאמר זה אתאר פרויקט שלצערי לא הגיע לתנאי לחימה עקב גורמים אנושיים. בקיצור: יותר מ-200 נתבים, הגדרה מהירה והכשרת צוות, איחוד לפי אזור, סינון רשתות ומארחים ספציפיים, אפשרות להוסיף כללים בקלות לכל המכשירים, רישום ובקרת גישה.

מה שמתואר להלן אינו מתיימר להיות מקרה מוכן, אבל אני מקווה שהוא יהיה שימושי עבורך בעת תכנון הרשתות שלך ומזעור שגיאות. אולי כמה נקודות ופתרונות לא נראים לך לגמרי נכונים - אם כן, כתוב בתגובות. הביקורת במקרה זה תהיה חוויה לאוצר המשותף. לכן, קורא, תסתכל על ההערות, אולי המחבר עשה טעות חמורה - הקהילה תעזור.

מספר הנתבים הוא 200-300, מפוזרים בערים שונות עם איכות שונה של חיבורי אינטרנט. יש צורך לעשות הכל בצורה יפה וברורה למנהלים המקומיים איך הכל יעבוד.

אז איפה כל פרויקט מתחיל? כמובן, עם TK.

1. ארגון תכנית רשת לכל הסניפים לפי דרישות הלקוח, פילוח רשת (מ-3 עד 20 רשתות בסניפים בהתאם לכמות המכשירים).
2. הגדרת מכשירים בכל סניף. בדיקת מהירות התפוקה האמיתית של הספק בתנאי הפעלה שונים.
3. ארגון הגנת המכשיר, ניהול רשימת הלבנים, זיהוי אוטומטי של התקפות עם רשימה שחורה אוטומטית לפרק זמן מסוים, מזעור השימוש באמצעים טכניים שונים המשמשים ליירט שליטה בגישה ומניעת שירות.
4. ארגון חיבורי VPN מאובטחים עם סינון רשת לפי דרישות הלקוח. מינימום 3 חיבורי VPN מכל סניף למרכז.
5. בהתבסס על נקודות 1, 2. בחר את הדרכים האופטימליות לבניית VPN-סובלני תקלות. אם יש הצדקה נכונה, ניתן לבחור בטכנולוגיית הניתוב הדינמי על ידי הקבלן.
6. ארגון תעדוף תעבורה לפי פרוטוקולים, יציאות, מארחים ושירותים ספציפיים אחרים המשמשים את הלקוח. (VOIP, מארחים עם שירותים חשובים)
7. ארגון ניטור ורישום אירועי נתב למענה של צוות תמיכה טכנית.

כפי שאנו מבינים, במספר מקרים המפרט הטכני נערך בהתאם לדרישות. את הדרישות הללו גיבשתי בעצמי, לאחר שהקשבתי לבעיות העיקריות. הוא הודה באפשרות שמישהו אחר יוכל לטפל בנקודות הללו.

באילו כלים ישמשו כדי לעמוד בדרישות אלו:

1. מחסנית ELK (לאחר זמן מה, התברר שייעשה שימוש ב-fluentd במקום logstash).
2. אנסיבל. כדי להקל על הניהול ושיתוף הגישה, נשתמש ב-AWX.
3. GITLAB. אין צורך להסביר כאן. איפה היינו בלי בקרת גרסאות של ההגדרות שלנו?
4. פגז כוח. יהיה סקריפט פשוט לדור הראשוני של התצורה.
5. דוקו ויקי, לכתיבת תיעוד ומדריכים. במקרה זה, אנו משתמשים ב-habr.com.
6. הניטור יתבצע באמצעות zabbix. לשם הבנה כללית ישרטט גם דיאגרמת חיבור.

נקודות התקנה של EFK

לגבי הנקודה הראשונה, אתאר רק את האידיאולוגיה שלפיה ייבנו המדדים. יש הרבה
מאמרים מצוינים על הגדרה וקבלה של יומנים ממכשירים שבהם פועל mikrotik.

אתעכב על כמה נקודות:

1. לפי התרשים, כדאי לשקול קבלת יומנים ממקומות שונים וביציאות שונות. לשם כך נשתמש בצבר יומנים. אנחנו גם רוצים ליצור גרפיקה אוניברסלית לכל הנתבים עם היכולת לשתף גישה. לאחר מכן אנו בונים את האינדקסים באופן הבא:

הנה חלק מהתצורה עם fluentd סוג elasticsearch
logstash_format true
index_name mikrotiklogs.north
logstash_prefix mikrotiklogs.north
flush_interval 10s
מארחים אלסטיקה: 9200
יציאה 9200

כך נוכל לשלב נתבים ולפלח לפי התוכנית - mikrotiklogs.west, mikrotiklogs.south, mikrotiklogs.east. למה לעשות את זה כל כך מסובך? אנו מבינים שיהיו לנו 200 מכשירים או יותר. אי אפשר לעקוב אחר הכל. עם גרסה 6.8 של elasticsearch, הגדרות אבטחה זמינות לנו (ללא רכישת רישיון), ובכך נוכל להפיץ זכויות צפייה בין עובדי תמיכה טכנית או מנהלי מערכת מקומיים.
טבלאות, גרפים - כאן אתה רק צריך להסכים - או להשתמש באותם, או שכל אחד יעשה מה שנוח לו.

2. על ידי רישום. אם נאפשר כניסה לכללי חומת האש, נהפוך את השמות ללא רווחים. ניתן לראות שבאמצעות תצורה פשוטה ב-fluentd, אנו יכולים לסנן נתונים וליצור פאנלים נוחים. התמונה למטה היא הנתב הביתי שלי.

3. לפי שטח תפוס ויולי עץ. בממוצע, עם 1000 הודעות לשעה, יומנים תופסים 2-3 מגה-בייט ליום, וזה, אתה מבין, לא כל כך הרבה. Elasticsearch גרסה 7.5.

ANSIBLE.AWX

למזלנו, יש לנו מודול מוכן לנתבים
ציינתי לגבי AWX, אבל הפקודות למטה עוסקות רק ב-ansible בצורתו הטהורה - אני חושב שלמי שעבד עם ansible, לא יהיו בעיות בשימוש ב-awx דרך ה-gui.

למען האמת, לפני זה הסתכלתי על מדריכים אחרים שבהם הם השתמשו ב-ssh, ולכולם היו בעיות שונות עם זמן תגובה ועוד המון בעיות. אני חוזר, זה לא הגיע למאבק , קח את המידע הזה כניסוי שלא הגיע רחוק יותר מעמדה של 20 נתבים.

עלינו להשתמש בתעודה או בחשבון. זה תלוי בך להחליט, אני בעד תעודות. איזו נקודה עדינה לגבי זכויות. אני נותן זכויות כתיבה - לפחות "איפוס תצורה" לא יעבוד.

לא אמורות להיות בעיות בהפקה, העתקה ויבוא של האישור:

רשימת פקודות קצרהבמחשב האישי שלך
ssh-keygen -t RSA, ענה על שאלות, שמור את המפתח.
העתק ל-mikrotik:
משתמש ssh-keys ייבוא ​​public-key-file=id_mtx.pub user=ansible
ראשית עליך ליצור חשבון ולהקצות לו זכויות.
בדיקת החיבור באמצעות האישור
ssh -p 49475 -i /keys/mtx [מוגן בדוא"ל]

הרשמה vi /etc/ansible/hosts
MT01 ansible_network_os=routeros ansible_ssh_port=49475 ansible_ssh_user= ansible
MT02 ansible_network_os=routeros ansible_ssh_port=49475 ansible_ssh_user= ansible
MT03 ansible_network_os=routeros ansible_ssh_port=49475 ansible_ssh_user= ansible
MT04 ansible_network_os=routeros ansible_ssh_port=49475 ansible_ssh_user= ansible

ובכן, ספר משחק לדוגמה: - שם: add_work_sites
מארחים: testmt
סדרתי: 1
חיבור: network_cli
משתמש_מרוחק: mikrotik.west
לאסוף_עובדות: כן
משימות:
- שם: הוסף אתרי_עבודה
routeros_command:
פקודות:
— רשימת כתובות חומת אש /ip add address=gov.ru list=work_sites comment=Ticket665436_Ochen_nado
— רשימת כתובות חומת אש /ip add address=habr.com list=work_sites comment=for_habr

כפי שאתה יכול לראות מהתצורה שלעיל, יצירת ספרי משחק משלך אינה קשה. זה מספיק כדי לשלוט היטב ב-cli mikrotik. בואו נדמיין מצב שבו אתה צריך להסיר את רשימת הכתובות עם נתונים מסוימים בכל הנתבים, אז:

מצא והסר/ip firewal address-list remove [find where list="gov.ru"]

בכוונה לא כללתי כאן את כל רשימת חומת האש כי... זה יהיה אינדיבידואלי עבור כל פרויקט. אבל דבר אחד אני יכול לומר בוודאות, השתמש רק ברשימת הכתובות.

לפי GITLAB הכל ברור. לא אתעכב על הנקודה הזו. הכל יפה למשימות בודדות, תבניות, מטפלים.

PowerShell

יהיו כאן 3 קבצים. למה Powershell? אתה יכול לבחור כל כלי ליצירת הגדרות, מה שנוח לך יותר. במקרה זה, לכולם יש Windows במחשב האישי שלו, אז למה לעשות את זה ב-bash כאשר powershell נוח יותר. איזה מהם נוח יותר?

התסריט עצמו (פשוט ומובן):[cmdletBinding()] Param(
[Parameter(Mandatory=$true)] [string]$EXTERNALIPADDDRESS,
[Parameter(Mandatory=$true)] [string]$EXTERNALIPROUTE,
[Parameter(Mandatory=$true)] [string]$BWorknets,
[Parameter(Mandatory=$true)] [string]$CWorknets,
[Parameter(Mandatory=$true)] [string]$BVoipNets,
[Parameter(Mandatory=$true)] [string]$CVoipNets,
[Parameter(Mandatory=$true)] [string]$CClientss,
[Parameter(Mandatory=$true)] [string]$BVPNWORKs,
[Parameter(Mandatory=$true)] [string]$CVPNWORKs,
[Parameter(Mandatory=$true)] [string]$BVPNCLIENTSs,
[Parameter(Mandatory=$true)] [string]$cVPNCLIENTSs,
[Parameter(Mandatory=$true)] [מחרוזת]$NAMEROUTER,
[Parameter(Mandatory=$true)] [string]$ServerCertificates,
[Parameter(Mandatory=$true)] [string]$infile,
[Parameter(Mandatory=$true)] [string]$outfile
)

Get-Content $infile | Foreach-Object {$_.Replace("EXTERNIP", $EXTERNALIPADDRESS)} |
Foreach-Object {$_.Replace("EXTROUTE", $EXTERNALIPROUTE)} |
Foreach-Object {$_.Replace("BWorknet", $BWorknets)} |
Foreach-Object {$_.Replace("CWorknet", $CWorknets)} |
Foreach-Object {$_.Replace("BVoipNet", $BVoipNets)} |
Foreach-Object {$_.Replace("CVoipNet", $CVoipNets)} |
Foreach-Object {$_.Replace("CClients", $CClientss)} |
Foreach-Object {$_.Replace("BVPNWORK", $BVPNWORKs)} |
Foreach-Object {$_.Replace("CVPNWORK", $CVPNWORKs)} |
Foreach-Object {$_.Replace("BVPNCLIENTS", $BVPNCLIENTSs)} |
Foreach-Object {$_.Replace("CVPNCLIENTS", $cVPNCLIENTSs)} |
Foreach-Object {$_.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:Winbox
wiki.mikrotik.com/wiki/Manual:Upgrading_RouterOS
wiki.mikrotik.com/wiki/Manual:IP/Fasttrack - כאן אתה צריך לדעת שכאשר fasttrack מופעל, כללי תעדוף התעבורה ועיצוב לא יעבדו - שימושי עבור מכשירים חלשים.

סמלים למשתנים:הרשתות הבאות נלקחות כדוגמה:
רשת עובדת 192.168.0.0/24
רשת VOIP 172.22.4.0/24
רשת 10.0.0.0/24 עבור לקוחות ללא גישה לרשת המקומית
192.168.255.0/24 רשת VPN לסניפים גדולים
172.19.255.0/24 רשת VPN לקטנים

כתובת הרשת מורכבת מ-4 מספרים עשרוניים, בהתאמה ABCD, ההחלפה פועלת על אותו עיקרון, אם בהפעלה היא מבקשת B, אז זה אומר שאתה צריך להזין את המספר 192.168.0.0 עבור הרשת 24/0, ועבור C = 0.
$EXTERNALIPADDDRESS - כתובת ייעודית מהספק.
$EXTERNALIPROUTE - מסלול ברירת מחדל לרשת 0.0.0.0/0
$BWorknets - רשת עבודה, בדוגמה שלנו יהיו 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.

לאילו נקודות כדאי לשים לב:

1. תוכנית רשת. עדיף לחבר אותו מיד בצורה קריאה. אקסל יספיק. לצערי, אני רואה לעתים קרובות מאוד שרשתות בנויות לפי העיקרון "הופיע סניף חדש, הנה /24 בשבילך." אף אחד לא מבין כמה מכשירים צפויים במיקום נתון או אם תהיה צמיחה נוספת. למשל, נפתחה חנות קטנה בה היה ברור בהתחלה שהמכשיר לא יהיה יותר מ-10, למה להקצות /24? לסניפים גדולים, להיפך, הם מקצים /24, ויש 500 מכשירים - אתה יכול פשוט להוסיף רשת, אבל אתה רוצה לחשוב על הכל בבת אחת.
2. כללי סינון. אם הפרויקט יניח שתהיה הפרדת רשתות ופילוח מקסימלי. שיטות עבודה מומלצות משתנות עם הזמן. בעבר, רשת PC ורשת מדפסות היו מחולקות, אבל עכשיו זה די נורמלי לא לחלק את הרשתות הללו. כדאי להשתמש בשכל הישר ולא ליצור רשתות משנה רבות שבהן אין צורך ולא לשלב את כל המכשירים לרשת אחת.
3. הגדרות "זהוב" בכל הנתבים. הָהֵן. אם החלטת על תוכנית. כדאי לחזות הכל מיד ולנסות לוודא שכל ההגדרות זהות - רק רשימת הכתובות וכתובות ה-IP שונות. אם מתעוררות בעיות, זמן איתור הבאגים יהיה קצר יותר.
4. נושאים ארגוניים חשובים לא פחות מאלו הטכניים. לעתים קרובות עובדים עצלנים מבצעים את ההמלצות הללו "ידנית", מבלי להשתמש בתצורות ותסריטים מוכנים, מה שבסופו של דבר מוביל לבעיות משום מקום.

על ידי ניתוב דינמי. נעשה שימוש ב-OSPF עם חלוקת אזורים. אבל זה ספסל מבחן; יותר מעניין להקים דברים כאלה בתנאי לחימה.

אני מקווה שאף אחד לא כועס שלא פרסמתי את תצורות הנתב. אני חושב שהקישורים יספיקו, ואז הכל תלוי בדרישות. וכמובן בדיקות, יש צורך בבדיקות נוספות.

אני מאחל לכולם להגשים את הפרויקטים שלהם בשנה החדשה. מי יתן והגישה שניתנה תהיה איתך!!!

מקור: www.habr.com