میرا نامکمل پراجیکٹ۔ 200 MikroTik راؤٹرز کا نیٹ ورک

سب کو سلام. یہ مضمون ان لوگوں کے لیے ہے جن کے پاس پارک میں بہت سارے Mikrotik ڈیوائسز ہیں، اور جو زیادہ سے زیادہ اتحاد کرنا چاہتے ہیں تاکہ ہر ڈیوائس سے الگ الگ رابطہ نہ ہو۔ اس مضمون میں، میں ایک پروجیکٹ کی وضاحت کروں گا جو بدقسمتی سے انسانی عوامل کی وجہ سے جنگی حالات تک نہیں پہنچ سکا۔ مختصراً: 200 سے زیادہ راؤٹرز، فوری سیٹ اپ اور عملے کی تربیت، علاقے کے لحاظ سے اتحاد، فلٹرنگ نیٹ ورکس اور مخصوص میزبان، تمام آلات میں آسانی سے قواعد شامل کرنے کی صلاحیت، لاگنگ اور رسائی کنٹرول۔

ذیل میں جو کچھ بیان کیا گیا ہے وہ ریڈی میڈ کیس ہونے کا بہانہ نہیں کرتا، لیکن مجھے امید ہے کہ یہ آپ کے نیٹ ورکس کی منصوبہ بندی کرتے وقت اور غلطیوں کو کم کرتے وقت آپ کے لیے مفید ثابت ہوگا۔ شاید کچھ نکات اور فیصلے آپ کو بالکل درست نہ لگیں - اگر ایسا ہے تو کمنٹس میں لکھیں۔ اس معاملے میں تنقید ایک عام گللک میں ایک تجربہ ہوگا۔ لہذا، قارئین، تبصرے میں دیکھو، شاید مصنف نے ایک سنگین غلطی کی ہے - کمیونٹی مدد کرے گی.

راؤٹرز کی تعداد 200-300 ہے، جو مختلف شہروں میں انٹرنیٹ کنکشن کے مختلف معیار کے ساتھ بکھرے ہوئے ہیں۔ یہ ضروری ہے کہ ہر چیز کو خوبصورت بنایا جائے اور مقامی منتظمین کو قابل رسائی طریقے سے سمجھانا چاہیے کہ سب کچھ کیسے کام کرے گا۔

تو ہر منصوبہ کہاں سے شروع ہوتا ہے؟ بالکل، کے ساتھ TK.

1. صارفین کی ضروریات کے مطابق تمام شاخوں کے لیے نیٹ ورک پلان کی تنظیم، نیٹ ورک کی تقسیم (برانچوں میں 3 سے 20 نیٹ ورکس، آلات کی تعداد کے لحاظ سے)۔
2. ہر برانچ میں ڈیوائسز لگائیں۔ مختلف کام کے حالات میں فراہم کنندہ کی اصلی بینڈوتھ کی جانچ کرنا۔
3. ڈیوائس پروٹیکشن کی تنظیم، وائٹ لسٹ کنٹرول، ایک مخصوص مدت کے لیے خودکار بلیک لسٹنگ کے ساتھ حملوں کا خود بخود پتہ لگانا، کنٹرول تک رسائی کو روکنے کے لیے استعمال ہونے والے مختلف تکنیکی ذرائع کے استعمال کو کم سے کم کرنا اور سروس سے انکار۔
4. کسٹمر کی ضروریات کے مطابق نیٹ ورک فلٹرنگ کے ساتھ محفوظ وی پی این کنکشنز کی تنظیم۔ ہر شاخ سے مرکز تک کم از کم 3 وی پی این کنکشن۔
5. پوائنٹس 1، 2 کی بنیاد پر۔ غلطی برداشت کرنے والا وی پی این بنانے کے بہترین طریقے منتخب کریں۔ متحرک روٹنگ ٹیکنالوجی، درست جواز کے ساتھ، ٹھیکیدار کی طرف سے منتخب کیا جا سکتا ہے.
6. پروٹوکولز، بندرگاہوں، میزبانوں اور صارف کے استعمال کردہ دیگر مخصوص خدمات کے ذریعے ٹریفک کی ترجیحات کی تنظیم۔ (VOIP، اہم خدمات کے ساتھ میزبان)
7. تکنیکی معاون عملے کے جواب کے لیے روٹر ایونٹس کی نگرانی اور لاگنگ کی تنظیم۔

جیسا کہ ہم سمجھتے ہیں، بعض صورتوں میں، ٹی او آر کو ضروریات سے مرتب کیا جاتا ہے۔ میں نے بنیادی مسائل کو سننے کے بعد اپنے طور پر یہ تقاضے وضع کیے ہیں۔ انہوں نے اس امکان کو تسلیم کیا کہ کوئی اور ان نکات پر عمل درآمد کر سکتا ہے۔

ان ضروریات کو پورا کرنے کے لیے کون سے اوزار استعمال کیے جائیں گے:

1. ELK stack (کچھ عرصے بعد، یہ سمجھا گیا کہ logstash کے بجائے fluentd استعمال کیا جائے گا)۔
2. جوابدہ انتظامیہ میں آسانی اور رسائی کے اشتراک کے لیے، ہم AWX استعمال کریں گے۔
3. GITLAB یہاں وضاحت کی ضرورت نہیں۔ جہاں ہماری تشکیلات کے ورژن کنٹرول کے بغیر۔
4. پاور شیل۔ تشکیل کی ابتدائی نسل کے لیے ایک سادہ اسکرپٹ ہوگا۔
5. ڈوکو ویکی، دستاویزات اور دستورالعمل لکھنے کے لیے۔ اس صورت میں، ہم habr.com استعمال کرتے ہیں۔
6. زبکس کے ذریعے مانیٹرنگ کی جائے گی۔ عام فہم کے لیے کنکشن ڈایاگرام بھی ہوگا۔

EFK سیٹ اپ پوائنٹس

پہلے نکتے پر میں صرف اس نظریے کو بیان کروں گا جس پر اشاریہ جات بنائے جائیں گے۔ بہت سے ہیں
میکروٹک چلانے والے آلات سے لاگ ترتیب دینے اور وصول کرنے کے بارے میں بہترین مضامین۔

میں کچھ نکات پر غور کروں گا:

1. اسکیم کے مطابق، مختلف جگہوں اور مختلف بندرگاہوں سے لاگ وصول کرنے پر غور کرنا ضروری ہے۔ ایسا کرنے کے لیے، ہم لاگ ایگریگیٹر استعمال کریں گے۔ ہم تمام راؤٹرز کے لیے یونیورسل گرافکس بھی بنانا چاہتے ہیں جس میں رسائی کا اشتراک کرنے کی صلاحیت ہو۔ پھر ہم مندرجہ ذیل اشاریہ جات بناتے ہیں:

یہاں fluentd کے ساتھ تشکیل کا ایک ٹکڑا ہے۔ لچکدار تلاش
logstash_format true
index_name mikrotiklogs.north
logstash_prefix mikrotiklogs.north
flush_interval 10s
میزبان لچکدار تلاش: 9200
بندرگاہ 9200

اس طرح، ہم پلان کے مطابق روٹرز اور سیگمنٹ کو یکجا کر سکتے ہیں - mikrotiklogs.west، mikrotiklogs.south، mikrotiklogs.east۔ اسے اتنا مشکل کیوں بناتے ہیں؟ ہم سمجھتے ہیں کہ ہمارے پاس 200 یا اس سے زیادہ آلات ہوں گے۔ ہر چیز کی پیروی نہ کریں۔ elasticsearch کے ورژن 6.8 کے بعد سے، حفاظتی ترتیبات ہمارے لیے دستیاب ہیں (لائسنس خریدے بغیر)، اس طرح، ہم تکنیکی معاون ملازمین یا مقامی نظام کے منتظمین کے درمیان دیکھنے کے حقوق تقسیم کر سکتے ہیں۔
میزیں، گرافس - یہاں آپ کو صرف اتفاق کرنا ہوگا - یا تو وہی استعمال کریں، یا ہر کوئی ایسا کرے جیسا کہ یہ اس کے لیے آسان ہوگا۔

2. لاگنگ کرکے۔ اگر ہم لاگ ان فائر وال رولز کو فعال کرتے ہیں، تو ہم خالی جگہوں کے بغیر نام بناتے ہیں۔ یہ دیکھا جا سکتا ہے کہ fluentd میں ایک سادہ ترتیب کا استعمال کرتے ہوئے، ہم ڈیٹا کو فلٹر کر سکتے ہیں اور آسان پینل بنا سکتے ہیں۔ نیچے دی گئی تصویر میرے گھر کا راؤٹر ہے۔

3. مقبوضہ جگہ اور نوشتہ جات کے مطابق۔ اوسطاً، فی گھنٹہ 1000 پیغامات کے ساتھ، لاگز 2-3 MB فی دن لیتے ہیں، جو آپ دیکھتے ہیں، اتنا زیادہ نہیں ہے۔ لچکدار تلاش کا ورژن 7.5۔

ANSIBLE.AWX

ہمارے لیے خوش قسمتی سے، ہمارے پاس روٹروز کے لیے ایک ریڈی میڈ ماڈیول ہے۔
میں نے AWX کے بارے میں نشاندہی کی، لیکن نیچے دیے گئے کمانڈز صرف اس کی خالص ترین شکل میں جواب دینے کے بارے میں ہیں - میرے خیال میں ان لوگوں کے لیے جنہوں نے جوابدہ کے ساتھ کام کیا ہے، gui کے ذریعے awx استعمال کرنے میں کوئی مسئلہ نہیں ہوگا۔

سچ پوچھیں تو، اس سے پہلے میں نے دوسرے گائیڈز کو دیکھا جہاں وہ ssh استعمال کرتے تھے، اور ہر ایک کو رسپانس ٹائم اور دیگر مسائل کے ایک گروپ کے ساتھ مختلف مسائل تھے۔ میں دہراتا ہوں، یہ جنگ تک نہیں پہنچی ، اس معلومات کو ایک تجربے کے طور پر لیں جو 20 راؤٹرز کے اسٹینڈ سے آگے نہیں بڑھی۔

ہمیں سرٹیفکیٹ یا اکاؤنٹ استعمال کرنے کی ضرورت ہے۔ فیصلہ آپ پر ہے، میں سرٹیفکیٹ کے لیے ہوں۔ حقوق کے بارے میں کچھ لطیف نکات۔ میں لکھنے کے حقوق دیتا ہوں - کم از کم "ری سیٹ کنفگ" کام نہیں کرے گا۔

سرٹیفکیٹ بنانے، کاپی کرنے اور درآمد کرنے میں کوئی مسئلہ نہیں ہونا چاہئے:

کمانڈز کی مختصر فہرستاپنے پی سی پر
ssh-keygen -t RSA، سوالات کے جواب دیں، کلید کو محفوظ کریں۔
mikrotik میں کاپی کریں:
user ssh-keys import 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
کنکشن: نیٹ ورک_کلی۔
remote_user: mikrotik.west
حقائق جمع کریں: ہاں
کام:
نام: Work_sites شامل کریں۔
routeros_command:
حکم:
- /ip فائر وال ایڈریس لسٹ ایڈریس=gov.ru list=work_sites comment=Ticket665436_Ochen_nado
- /ip فائر وال ایڈریس لسٹ ایڈریس=habr.com list=work_sites comment=for_habr

جیسا کہ آپ مندرجہ بالا ترتیب سے دیکھ سکتے ہیں، آپ کی اپنی پلے بکس کو مرتب کرنا ایک آسان معاملہ ہے۔ cli mikrotik میں مہارت حاصل کرنا کافی اچھا ہے۔ اس صورت حال کا تصور کریں جہاں آپ کو تمام راؤٹرز پر مخصوص ڈیٹا کے ساتھ ایڈریس لسٹ کو ہٹانے کی ضرورت ہے، پھر:

تلاش کریں اور ہٹا دیں۔/ip فائروال ایڈریس لسٹ ہٹا دیں [find where list="gov.ru"]

میں نے جان بوجھ کر پوری فائر وال کی فہرست یہاں شامل نہیں کی۔ یہ ہر منصوبے کے لئے انفرادی ہو جائے گا. لیکن میں ایک بات یقینی طور پر کہہ سکتا ہوں، صرف ایڈریس لسٹ استعمال کریں۔

GITLAB کے مطابق، سب کچھ واضح ہے۔ میں اس لمحے پر نہیں رہوں گا۔ انفرادی کاموں، ٹیمپلیٹس، ہینڈلرز کے لحاظ سے ہر چیز خوبصورت ہے۔

PowerShell کے

3 فائلیں ہوں گی۔ پاورشیل کیوں؟ تشکیلات پیدا کرنے کا ٹول ہر وہ شخص منتخب کر سکتا ہے جو زیادہ آرام دہ ہو۔ اس صورت میں، ہر کسی کے پی سی پر ونڈوز ہوتی ہے، تو اسے باش پر کیوں کریں جب پاور شیل زیادہ آسان ہو۔ جو زیادہ آرام دہ ہے۔

اسکرپٹ خود (سادہ اور قابل فہم):[cmdletBinding()] Param(
[پیرامیٹر(لازمی=$سچ)] [string]$EXTERNALIPADDRESS،
[پیرامیٹر(لازمی=$سچ)] [string]$EXTERNALIPROUTE،
[پیرامیٹر(لازمی=$سچ)] [string]$BWorknets،
[پیرامیٹر(لازمی=$سچ)] [string]$CWorknets،
[پیرامیٹر(لازمی=$سچ)] [string]$BVoipNets،
[پیرامیٹر(لازمی=$سچ)] [string]$CVoipNets،
[پیرامیٹر(لازمی=$سچ)] [string]$CClientss،
[پیرامیٹر(لازمی=$سچ)] [string]$BVPNWORKs،
[پیرامیٹر(لازمی=$سچ)] [string]$CVPNWORKs،
[پیرامیٹر(لازمی=$سچ)] [string]$BVPNCLIENTSs،
[پیرامیٹر(لازمی=$سچ)] [string]$cVPNCLIENTSs،
[پیرامیٹر(لازمی=$سچ)] [string]$NAMEROUTER،
[پیرامیٹر(لازمی=$سچ)] [string]$ServerCertificates,
[پیرامیٹر(لازمی=$سچ)] [string]$infile،
[پیرامیٹر(لازمی=$سچ)] [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)} | سیٹ مواد $outfile

میں آپ سے معافی چاہتا ہوں، میں تمام اصول نہیں بنا سکتا۔ یہ خوبصورت نہیں ہو گا. بہترین طریقوں سے رہنمائی کرتے ہوئے آپ خود اصول بنا سکتے ہیں۔

مثال کے طور پر، یہاں ان لنکس کی فہرست ہے جن کے ذریعے میری رہنمائی کی گئی تھی:wiki.mikrotik.com/wiki/Manual:Securing_Your_Router
wiki.mikrotik.com/wiki/Manual:آئی پی/فائر وال/فلٹر
wiki.mikrotik.com/wiki/Manual:OSPF- مثالیں۔
wiki.mikrotik.com/wiki/Drop_port_scanners
wiki.mikrotik.com/wiki/Manual: ون باکس
wiki.mikrotik.com/wiki/Manual: اپ گریڈنگ_روٹر او ایس
wiki.mikrotik.com/wiki/Manual:IP/Fasttrack - یہاں آپ کو یہ جاننے کی ضرورت ہے کہ جب فاسٹ ٹریک کو فعال کیا جائے گا، تو ٹریفک کی ترجیح اور شکل دینے کے اصول کام نہیں کریں گے - کمزور آلات کے لیے مفید ہے۔

متغیر کنونشنز:مندرجہ ذیل نیٹ ورکس کو مثال کے طور پر لیا جاتا ہے۔
192.168.0.0/24 ورکنگ نیٹ ورک
172.22.4.0/24 VOIP نیٹ ورک
LAN تک رسائی کے بغیر کلائنٹس کے لیے 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 کے لیے نمبر داخل کرنے کی ضرورت ہے۔ .
$EXTERNALIPADDRESS - فراہم کنندہ سے مختص کردہ پتہ۔
$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 - اس فائل کے راستے کی وضاحت کریں جہاں سے ہم config پڑھیں گے، مثال کے طور پر D:config.txt (کوٹس اور خالی جگہوں کے بغیر انگریزی کا بہتر راستہ)
$outfile - اس راستے کی وضاحت کریں جہاں محفوظ کرنا ہے، مثال کے طور پر D:MT-test.txt

میں نے جان بوجھ کر واضح وجوہات کی بنا پر مثالوں میں پتے تبدیل کر دیئے۔

میں نے حملوں اور غیر معمولی رویے کا پتہ لگانے کا نقطہ نظر چھوڑ دیا - یہ ایک الگ مضمون کا مستحق ہے۔ لیکن یہ بتانے کے قابل ہے کہ اس زمرے میں آپ زیبکس + سے elasticsearch سے کرل ڈیٹا کی نگرانی کرنے والے ڈیٹا ویلیوز کا استعمال کر سکتے ہیں۔

کن نکات پر توجہ مرکوز کرنی ہے:

1. نیٹ ورک پلان۔ اسے پڑھنے کے قابل شکل میں لکھنا بہتر ہے۔ ایکسل کافی ہے۔ بدقسمتی سے، میں اکثر دیکھتا ہوں کہ نیٹ ورک اس اصول کے مطابق مرتب کیے گئے ہیں "ایک نئی برانچ سامنے آئی ہے، یہ ہے /24 آپ کے لیے۔" کسی کو یہ معلوم نہیں ہوتا ہے کہ کسی مخصوص مقام پر کتنے آلات کی توقع ہے اور کیا مزید ترقی ہوگی۔ مثال کے طور پر، ایک چھوٹا اسٹور کھلا ہے، جس میں ابتدائی طور پر یہ واضح ہے کہ ڈیوائس 10 سے زیادہ نہیں ہوگی، کیوں مختص / 24؟ بڑی شاخوں کے لیے، اس کے برعکس، وہ /24 مختص کرتے ہیں، اور وہاں 500 ڈیوائسز ہیں - آپ صرف ایک نیٹ ورک شامل کر سکتے ہیں، لیکن آپ فی الفور سب کچھ سوچنا چاہتے ہیں۔
2. فلٹرنگ کے قواعد۔ اگر پروجیکٹ فرض کرتا ہے کہ نیٹ ورکس کی علیحدگی اور زیادہ سے زیادہ سیگمنٹیشن ہوگی۔ بہترین طرز عمل وقت کے ساتھ بدلتے رہتے ہیں۔ پہلے، وہ پی سی نیٹ ورک اور پرنٹر نیٹ ورک کا اشتراک کرتے تھے، اب ان نیٹ ورکس کا اشتراک نہ کرنا بالکل عام بات ہے۔ عقل کا استعمال کرنا اور بہت سے ذیلی نیٹ ورک تیار نہ کرنا جہاں ان کی ضرورت نہ ہو اور تمام آلات کو ایک نیٹ ورک میں نہ ملانا قابل قدر ہے۔
3. تمام راؤٹرز پر "سنہری" ترتیبات۔ وہ. اگر آپ کے پاس کوئی منصوبہ ہے۔ یہ سب کچھ فوری طور پر دیکھنے اور اس بات کو یقینی بنانے کی کوشش کرنے کے قابل ہے کہ تمام ترتیبات ایک جیسی ہیں - صرف مختلف ایڈریس لسٹ اور آئی پی ایڈریس ہیں۔ مسائل کی صورت میں ڈیبگنگ کا وقت کم ہوگا۔
4. تنظیمی پہلو تکنیکی پہلوؤں سے کم اہم نہیں ہیں۔ اکثر، سست ملازمین ریڈی میڈ کنفیگریشنز اور اسکرپٹس کا استعمال کیے بغیر ان سفارشات پر "دستی طور پر" عمل کرتے ہیں، جو بالآخر شروع سے ہی مسائل کا باعث بنتے ہیں۔

متحرک روٹنگ کے ذریعے۔ زوننگ کے ساتھ OSPF استعمال کیا گیا تھا۔ لیکن یہ ایک ٹیسٹ بینچ ہے، جنگی حالات میں ایسی چیزیں قائم کرنا زیادہ دلچسپ ہوتا ہے۔

مجھے امید ہے کہ کوئی بھی ناراض نہیں ہوا تھا کہ میں نے راؤٹرز کی ترتیب پوسٹ نہیں کی۔ میرا خیال ہے کہ روابط کافی ہوں گے، اور پھر یہ سب ضروریات پر منحصر ہے۔ اور یقیناً ٹیسٹ، مزید ٹیسٹ کی ضرورت ہے۔

میری خواہش ہے کہ نئے سال میں ہر کوئی اپنے منصوبوں کو عملی جامہ پہنائے۔ ممکن ہے رسائی آپ کے ساتھ ہو!!!

ماخذ: www.habr.com