توضیح مسیر و پروب‌ها

«چرا دفتر به وب‌سرور نمی‌رسد؟» پاسخ دادن به این سؤال معمولاً یعنی ورود به روتر پشت روتر و خواندن جدول‌های مسیریابی و access listها. **توضیح مسیر** (Path Explain) این کار را برایتان انجام می‌دهد، از روی آخرین چیزی که دستگاه‌های یک [سایت](/docs/fa/network-sites) گفته‌اند: - **همهٔ گام‌ها.** روتی که هر دستگاه به کار می‌برد (`172.16.20.0/24 via 10.0.2.2, OSPF`)، اینترفیسی که از آن خارج می‌شود، ACLها و قانون‌های فایروالی که از آن‌ها می‌گذرد، و قانونی که اجازهٔ عبور داد. - **جایی که می‌ایستد، و چرا.** دستگاه، اینترفیس و قانون دقیقی که آن را دور می‌اندازد؛ یا روتِ ناموجود، حلقهٔ مسیریابی، اینترفیسی که قطع است. - **راه برگشت.** پاسخ هم دنبال می‌شود. پاسخی که از راه دیگری از یک فایروال حالت‌دار (stateful) بگذرد، به‌عنوان invalid دور انداخته می‌شود؛ همان مشکل کلاسیک **مسیریابی نامتقارن**، و توضیح مسیر این را می‌گوید. - **راه‌حل**، با دستورهای سازندهٔ همان دستگاه: قانون permit را کجا اضافه کنید، کدام روت استاتیک را از طریق کدام همسایه اضافه کنید. **پروب‌ها** روی جمع‌آوری‌کنندهٔ سایت اجرا می‌شوند: پینگ، یک پورت TCP، یک URL از نوع HTTP(S)، یک جست‌وجوی DNS؛ هر ۳۰ ثانیه تا یک ساعت. وقتی یکی ناموفق شود، توضیح مسیر می‌گوید آیا علتش شبکه است یا نه. زارین فقط پیشنهاد می‌دهد و هرگز دستگاهی را تغییر نمی‌دهد. ## جمع‌آوری‌کننده برای این کار چه می‌خواند جمع‌آوری‌کننده (zev 0.8 یا جدیدتر) دو چیز دیگر هم از هر دستگاه می‌خواند، باز هم فقط با دستورهای خواندنی: | سازنده | جدول مسیریابی | فیلترها | |---|---|---| | Cisco IOS / IOS-XE | `show ip route` | ACLهای روی اینترفیس‌ها (`ip access-group`)، از کانفیگ | | Huawei VRP | `display ip routing-table` | ACLهای `traffic-filter` روی اینترفیس‌ها، از کانفیگ | | MikroTik RouterOS | `/ip route print terse` | `/ip firewall filter`، همراه با address listها و interface listها | | FRRouting، VyOS، لینوکس | `ip -j route` (جدول کرنل) | iptables (`iptables-save`) و nftables (`nft -j list ruleset`) | در لینوکس، خواندن فایروال دسترسی root می‌خواهد. به ورودِ جمع‌آوری‌کننده اجازه دهید فقط همین دو دستور خواندنی را اجرا کند: ```text # /etc/sudoers.d/zev-site netops ALL=(root) NOPASSWD: /usr/sbin/iptables-save, /usr/sbin/nft -j list ruleset ``` بدون آن، توضیح مسیر می‌گوید نتوانست فایروال آن دستگاه را بخواند، و وانمود نمی‌کند که فایروالی ندارد. زبانهٔ **روت‌ها و فیلترها**ی هر دستگاه آنچه خوانده شده را نشان می‌دهد. یک آدرس را جست‌وجو کنید تا روت‌هایی که شاملش هستند، و اینکه کدام استفاده می‌شود، را ببینید. ## بپرسید: چرا A به B نمی‌رسد؟ در زبانهٔ **مسیرها**ی سایت: - **از** و **به**: یک آدرس IPv4، نام یک دستگاه، یا `collector` (آدرس خودِ جمع‌آوری‌کننده). - **پروتکل** و **پورت**: TCP یا UDP با پورت، ICMP (پینگ)، یا هر IP. - **ورود از** (اختیاری): دستگاهی که ترافیک از آن وارد می‌شود، وقتی مبدأ روی هیچ‌کدام از زیرشبکه‌های سایت نیست (ترافیک اینترنت یا VPN) یا وقتی یک زیرشبکه دو gateway دارد. مثلاً از `192.168.10.20` (یک لپ‌تاپ) به `172.16.20.10` (یک سرور)، پورت TCP 80: ```text Blocked by a filter sw1 drops it (outbound on GigabitEthernet0/2): SERVERS-OUT, rule 40 deny ip any any log gw bridge → ether2 route 172.16.0.0/16 via 10.0.1.2 (static) allowed · firewall, passing through · forward (no rule matched) sw1 Gi0/1 → Gi0/2 route 172.16.20.0/24 via 10.0.2.2 (ospf) dropped · outbound on Gi0/2 · SERVERS-OUT #40 deny ip any any log ``` ## خواندن پاسخ | پاسخ | معنی | |---|---| | در دسترس، در هر دو جهت | می‌رسد و پاسخ هم برمی‌گردد. | | از سایت خارج می‌شود | به سمت گام بعدی‌ای می‌رود که از دستگاه‌های سایت نیست (یک ISP، سایتی دیگر). زارین آن‌سوتر را نمی‌بیند. | | می‌رسد، اما پاسخ برنمی‌گردد | درخواست می‌رسد؛ پاسخ در راه برگشت دور انداخته می‌شود (اغلب مسیریابی نامتقارن). | | یک فیلتر جلویش را گرفته | یک ACL یا قانون فایروال آن را دور می‌اندازد. پاسخ، خودِ قانون را نقل می‌کند. | | روتی نیست | دستگاهی هیچ روتی به مقصد ندارد، و روت پیش‌فرض هم ندارد. | | یک روت آن را دور می‌اندازد | روتی آن را به Null0 یا blackhole می‌فرستد. | | حلقهٔ مسیریابی | دو یا چند دستگاه آن را به هم پاس می‌دهند. | | یک اینترفیس در مسیر قطع است | روت از اینترفیسی استفاده می‌کند که قطع یا خاموش (shutdown) است. | | شاید مسدود شود | پیش از قانونِ تعیین‌کننده، قانونی هست که زارین نمی‌تواند کامل ارزیابی‌اش کند (object group، named set، time range). پاسخ آن را نام می‌برد. | | نمی‌شود گفت | چیزی کم است: روت‌های دستگاهی جمع‌آوری نشده، یا مبدأ روی هیچ زیرشبکه‌ای از سایت نیست. | وقتی **مسیرهای هم‌هزینه** (ECMP) وجود دارد، هرکدام دنبال می‌شود و می‌توانید میانشان جابه‌جا شوید. **نمایش روی نقشه** دستگاه‌های سر راه را برجسته می‌کند. **این پاسخ بر چه تکیه دارد** زیر هر پاسخ فهرست می‌شود: دستگاهی که فایروالش خوانده نشد، دو gateway روی زیرشبکهٔ مبدأ، NAT در مسیر. ## راه‌حل: قانون ACL، روت، اینترفیس زیر هر پاسخ ناموفق، زارین دستورهای همان دستگاه را می‌دهد: ```text # Cisco: درست پیش از قانونی که آن را دور می‌اندازد ip access-list extended SERVERS-OUT 35 permit tcp host 192.168.10.20 host 172.16.20.10 eq 80 # Huawei: شمارهٔ قانونی کوچک‌تر از قانونِ دوراندازنده acl number 3001 rule 2 permit tcp source 192.168.10.20 0 destination 172.16.20.10 0 destination-port eq 3389 # MikroTik: پیش از قانونی که آن را دور می‌اندازد /ip firewall filter add chain=forward action=accept protocol=tcp src-address=192.168.10.66 dst-address=172.16.20.10 dst-port=443 place-before=[find comment="quarantine"] # iptables / nftables iptables -I FORWARD 2 -s 10.81.1.10 -d 10.81.2.10 -p tcp --dport 8080 -j ACCEPT nft insert rule inet fw forward position 4 ip saddr 10.81.1.10 ip daddr 10.81.2.10 udp dport 53 accept ``` برای **روتی نیست**، زارین روی همان زیرشبکه دنبال همسایه‌ای می‌گردد که راه را بلد است، و روت استاتیک از طریق آن را می‌دهد (`ip route`، `ip route-static`، `/ip route add`، `set protocols static` در VyOS). برای اینترفیسی که **خاموش (shutdown)** است، دستوری که روشنش می‌کند. وقتی جایی برای شمارهٔ قانون نیست (مثلاً sequence 20 و 21 در Cisco بدون فاصله)، راه‌حل اول فهرست را از نو شماره‌گذاری می‌کند (`ip access-list resequence` و `step` در Huawei). پیش از اجرا دستورها را بخوانید. permit برای یک میزبان محدودترین راه‌حل است؛ شاید راه‌حل گسترده‌تری بخواهید. ## وقتی پاسخ از راه دیگری برمی‌گردد ACLهای بدون حالت (Cisco، Huawei) برای پاسخ هم قانون می‌خواهند، مگر اینکه یکی ترافیک `established` را مجاز کند. فایروال‌های حالت‌دار (MikroTik، iptables، nftables) وقتی درخواست را دیده باشند، پاسخ را برمی‌گردانند. اگر پاسخ از فایروالی برگردد که درخواست هرگز از آن نگذشته، آن فایروال پاسخی به چیزی ناشناخته می‌بیند و آن را **invalid** دور می‌اندازد؛ کانفیگ پیش‌فرض MikroTik دقیقاً همین کار را می‌کند. توضیح مسیر پاسخ را از هر دستگاه با آنچه همان دستگاه دیده دنبال می‌کند، پس این حالت را پیدا می‌کند. ## مسیرهای پایش‌شده پس از یک پاسخ، **این مسیر را پایش کن** را بزنید و نامی به آن بدهید (`users-to-web`). هر بار دستگاهی در مسیر روت‌ها، فیلترها یا اینترفیس‌های متفاوتی گزارش کند، زارین دوباره بررسی‌اش می‌کند. وقتی پاسخ تغییر کند، **تغییرات** آن را با دستگاه و قانون می‌گوید («watched path users-to-web: Reachable → Blocked by a filter, at sw1: deny ip any any»). تغییر ACLی که مسیری را خراب کرده، چند دقیقه بعد دیده می‌شود، نه وقتی کاربران زنگ می‌زنند. ## آنچه هنوز دنبال نمی‌شود - **NAT.** وقتی دستگاهی در مسیر NAT انجام می‌دهد، پاسخ این را می‌گوید و آدرس‌های اصلی را دنبال می‌کند. - **VRFها و policy routing.** فقط جدول مسیریابی اصلی (global) خوانده می‌شود. - **فایروال zone-based در Cisco** و **`match-order auto` در Huawei.** پاسخ می‌گوید که دستگاهی آن‌ها را دارد. - **IPv6.** ## پروب‌ها در زبانهٔ **سلامت** سایت، یک پروب اضافه کنید. جمع‌آوری‌کننده آن را با فاصله‌ای که انتخاب می‌کنید اجرا می‌کند (۳۰ ثانیه تا یک ساعت): | نوع | مقصد | آنچه اندازه‌گیری می‌شود | |---|---|---| | پینگ | یک آدرس یا نام | زمان رفت‌وبرگشت و ازدست‌رفتن (۴ echo) | | پورت TCP | یک آدرس یا نام، و یک پورت | مدت برقراری اتصال. **رد شد** (میزبان پاسخ داد، چیزی گوش نمی‌دهد) از **بی‌پاسخ** (در راه دور انداخته شد) جدا گفته می‌شود | | HTTP(S) | یک URL | زمان پاسخ و کد وضعیت. پیش‌فرض: 2xx و 3xx سالم است. کد مورد انتظار را تعیین کنید (`200`، `2xx`، `200,401`) | | جست‌وجوی DNS | یک نام، یا `name@server` برای پرسیدن از یک سرور خاص | زمان پاسخ. اختیاری: آدرسی که پاسخ باید شاملش باشد | هر پروب روز گذشته‌اش (یک ستون برای هر نیم ساعت)، درصد بررسی‌های موفق، و نموداری برای ۶ ساعت، یک روز یا یک هفته را نشان می‌دهد. نتایج یک هفته نگه داشته می‌شوند. یک پروب پس از دو شکست پشت سر هم **ناموفق** می‌شود و پس از یک موفقیت به حالت عادی برمی‌گردد. هر دو در **تغییرات** دیده می‌شوند. وقتی ناموفق می‌شود، زارین توضیح مسیر را از جمع‌آوری‌کننده تا مقصد اجرا می‌کند: - اگر مسیر شبکه سالم باشد، مشکل در خود مقصد است (سرویس از کار افتاده، پورت بسته است). - اگر نه، دستگاه و قانون را نام می‌برد. **باز کردن در توضیح مسیر** کل پاسخ را نشان می‌دهد. یک پروب را از shell جمع‌آوری‌کننده امتحان کنید، همان‌طور که سرویس اجرایش می‌کند: ```bash zev site probe ping 10.0.0.10 zev site probe tcp 10.0.0.10:443 zev site probe http https://intranet.example/health --expect 200 zev site probe dns intranet.example@10.0.0.53 --expect 10.0.0.10 ``` ## تأخیر میان سایت‌ها: مش و نقشهٔ سلامت با روشن بودن **مش** (زبانهٔ سلامت)، جمع‌آوری‌کنندهٔ یک سایت، جمع‌آوری‌کننده‌های سایت‌های دیگرتان را که مش‌شان روشن است پینگ می‌کند. سپس صفحهٔ **سایت‌ها** یک **نقشهٔ سلامت** نشان می‌دهد: تأخیر و ازدست‌رفتن میان هر دو سایت، که سطرهایش جایی است که پینگ از آن شروع می‌شود. قطع شدن لینک میان دو سایت در هر دو دیده می‌شود. ## محدودیت‌ها رایگان: ۱۰ پروب و ۱۰ مسیر پایش‌شده برای هر سایت. پریمیوم: ۳۰۰ پروب و ۲۰۰ مسیر پایش‌شده برای هر سایت. پروب‌های مش شمرده نمی‌شوند.