د VPN سایټونو کې د روتینګ لوپ او د روت فلیپینګ ترمنځ توپیر څنګه وپېژنو
د روتینګ لوپ او فلیپینګ روت ورته وقفه لرونکې زیان رامنځته کوي. په ګیټوېو باندې درې کتنې د هر څه د بدلولو دمخه دواړه بېلوي.
دوه سایټونه، یو تونل او یو لرې پریفکس چې یو څه وخت ځواب وایي او بیا چوپ شي۔ لومړنی غبرګون دا دی چې دې ته د روتینګ لوپ ووایو، او کله ناکله دا سمه ده۔ خو لوپ او فلیپینګ روت یوه شکایت جوړوي او مخالف ترمیم ته اړتیا لري: یو د لیږد پرېکړه ده چې هېڅکله نه پای ته رسېږي، بل هغه پریفکس دی چې تل له جدول څخه وځي۔ درې مشاهدې دواړه بېلوي، او درې واړه له ګیټوې کمانډ لاین څخه راټولولی شئ، مخکې لدې چې فلټر ته لاس وروړئ یا تونل بیا پیل کړئ۔
لوپ په یوه یوه ټوپ پریکړه کیږي۔ سایټ A د منزل لپاره B د بل ټوپ په توګه ټاکي، B د هماغه منزل لپاره A ټاکي، او پاکټ له دوو ګرځېدو وروسته په TTL پای ته رسېږي۔ فلیپینګ بیا د روتینګ پروتوکول لخوا پریکړه کیږي: پریفکس بیرته اخیستل کیږي، بیا نصب کیږي یا د بدیل بل ټوپ سره بدلیږي، له همدې کبله ځینې پاکټونه اصلاً روټ نلري، خو نور یو بشپړ ښه روټ تعقیبوي۔
هغه درې کتنې چې پوښتنه حل کوي
د لومړنۍ پرېکړې لپاره پاکټ نیول اړین نه دي۔ تاسې ته په دواړو سرونو کې د پریفکس حالت، هغه بل ټوپ چې هر اړخ یې ټاکي، او د ټوپونو شمېر چې یا تکرارېږي یا نه، ته اړتیا ده۔ که چېرې ټرافیک ناکامېږي او پریفکس لا هم په هماغه بل ټوپ نصب وي، لوپ د لیږد په لار کې دی۔ که پریفکس ورک شي او بیرته راشي، نقصان له لیږد څخه پورته دی او ترمیم د روتینګ پروتوکول دی، نه د سټاټیک روټ۔
| Observation | Routing loop | Route flapping |
|---|---|---|
| Prefix in the table | Installed, same next hop throughout | Withdrawn and reinstalled, or next hop alternates |
| Hop count | Reaches zero at the same two gateways | Expires only while the prefix is missing |
| Failure shape | Consistent loss for that prefix from every source | Bursts, often after a link or peer event |
| Where the fix belongs | The site that owns the prefix, plus filters on the transit path | Advertisement, hold timers, or the flapping link |
له پیل دمخه یوه خبرداری۔ که دا د هغه تونل له لارې لولئ چې لوپ کوي، د روټ په بدلولو سره ستاسې غونډه مري۔ هغه کنسول یا مدیریتي لار پرانیزئ چې د هغه پریفکس پورې تړلې نه وي چې تاسې یې د ترمیم په حال کې یاست۔
لومړۍ کتنه: پریفکس ټینګ دی که خوځېږي
له کرنل څخه وپوښتئ چې څه نصب کړي، نه دا چې کانفګریشن فایل څه ژمنه کوي۔ په لینکس ګیټوې کې ip route get 10.20.30.40 هغه لټون کوي چې د لیږد لار یې کوي، د پالیسۍ جدولونو په ګډون، خو ip route show 10.20.30.0/24 ننوتل خپله ښیي۔ ip monitor route هر بدلون د رامنځته کېدو په شیبه خپروي، او دا د پریفکس د راتلو او تلو کتلو ترټولو ژر لار ده۔
په هغه روټر کې چې FRR یا BIRD ګرځوي، د لیږد جدول په زړه پورې نه دی۔ show ip bgp 10.20.30.0/24 ټاکل شوې لار او د هغې کاري وخت بیرته راګرځوي؛ کاري وخت چې هره څو دقیقې بیا تنظیمېږي، هغه فلیپینګ دی چې نوم ورکولی شئ، نه لوپ۔ show ip bgp summary د ګاونډي حالت او د پریفکسونو شمېر ښیي، له همدې کبله تل رالویدونکی ملګری د لیږد له لارې تور لرې کوي۔
له هر څه بدلولو دمخه ځواب ولیکئ۔ لس دقیقې ټینګ پاتې کېدل هغه وخت چې پینګونه ناکام شول، او په لسو دقیقو کې څلور ځله ورکېدل، بېلابېلو راتلونکو ګامونو ته رسوي۔ دوهم حالت د سټاټیک روټ هره تیوري بې ارزښته کوي۔
دوهمه کتنه: ایا بل ټوپ بیرته د راتلو تونل ته اشاره کوي
لوپ د دوو ګیټوېو د موافقې غوښتنه کوي۔ په هغه سایټ کې چې پاکټ ترلاسه کوي، هغه لار وګورئ چې پاکټ به د وتلو لپاره کاروي: د ریښتیني سرچینې پتې سره ip route get 10.20.30.40 from 10.10.5.20، ځکه چې د پالیسۍ قاعده کېدای شي له اصلي جدول څخه بېل ځواب ورکړي۔ بیا په هغه سایټ کې لټون تکرار کړئ چې لیږلی یې دی۔ که هر اړخ د هماغه پریفکس لپاره بل ټاکي، لوپ ثابت شو او هېڅ نیول به څه اضافه نه کړي۔
سبب نږدې تل هغه اعلان وي چې تونل نه باید تېر شوی وای۔ تونل ته بیا ویشل شوی ډیفالټ روټ، هغه مجموعه چې د لرې سایټ خپله فرعي شبکه پوښي، یا د احتیاط لپاره ملګري ته اشاره کوونکی سټاټیک روټ — ټول هغه یو شان متقابل بل ټوپ جوړوي۔ تونل کېدای شي بشپړ جوړ شوی وي او بیا هم ټرافیک په ګرد کې بوځي؛ د strongSwan د لیږد یادښتونه د دې اړتیا روتینګ اړخ بیانوي۔
WireGuard خپله یادښت ته وړ دی، ځکه چې د تور لګولو لپاره هېڅ اعلان نشته۔ wg show د هر ملګري AllowedIPs لیست کوي، او کرنل د ملګري لپاره منزل یوازې هغه وخت مني چې په هماغه حد کې وي۔ هلته لوپ یو له بل سره تېرېدونکی AllowedIPs حد یا هغه سټاټیک روټ دی چې د انټرفیس له لارې بیرته اشاره کوي، له همدې کبله ترمیم یوازې په هماغه دوو ځایونو کې دی۔
درېمه کتنه: د ټوپونو شمېر ولولئ، ستوري نه
traceroute -n -I 10.20.30.40 او mtr -n -r -c 20 10.20.30.40 دواړه لار ښیي، او ICMP حالت ډېری وخت له هغه فلټرنګ څخه ژغورل کیږي چې UDP ازموینې خوري۔ لوپ د هماغه دوو ګیټوې پتو د لنډ تکرارېدونکي ترتیب په څېر ښکاري، او هربار TTL لوړېږي۔ لوېدل د وروستي ځواب ویونکي ګیټوې وروسته د ستورو په څېر ښکاري، او یو خاموش ټوپ د هیچا ثبوت نه دی۔
کله چې لار مبهمه وي، په تار باندې TTL ولولئ۔ په دواړو ګیټوېو tcpdump -ni any -vv icmp د هر پاکټ TTL او د وخت تېرېدو هر ځواب سرچینه ښیي۔ که پاکټ لرې سایټ ته د هغه ټوپونو له شمېر څخه کم TTL سره ورسیږي چې لار یې درلودلی شي، یو څه هغه ټوپونه زیاتوي چې traceroute یې نه ښیي، او دا هغه وخت پېښېږي چې د یو سایټ فایر وال د بل په استازیتوب ازموینو ته ځواب وایي۔
د پریفکس مالک ترمیم کړئ، بیا دواړه لوري وګورئ
پرېکړه وکړئ چې کوم سایټ منزل جوړوي او کومې ترانزیټي لارې اجازه لري، بیا په هماغه مالک کې اعلان یا سټاټیک روټ بدل کړئ۔ د ترلاسه کوونکي سایټ سمول زړه راښکونکی او معمولاً غلط دی: دا د یو پریفکس لپاره لوپ پټوي او بد اعلان د بل لپاره په خپل ځای پرېږدي۔ د روټ ټګونه، د ویش لیستونه او د split-horizon قواعد د دې لپاره دي چې دا په سرچینه کې ودروي، او له یو پریفکس سره سمون خوړونکي فلټر څخه ارزان دي۔
له بدلون وروسته تلل او بیرته راتلل بېل بېل وګورئ، ځکه چې لوپ کېدای شي د تور سوري سره بدل شي پرته له دې چې په نښه کې څرګنده ښه والی راشي۔ ip route get له دواړو سرو څخه چل کړئ، ټرافیک له هغه هوسټ څخه ولیږئ چې ګیټوې نه دی، او ip monitor route لږ تر لږه د یو نیولو ټایمر لپاره پرېږدئ چې فلیپینګ د ترمیم سره غلط وانګېرل شي۔
له هر څه بدلولو دمخه دا پنځه ټکي تایید کړئ: پریفکس ټینګ دی که خوځېږي، په دواړو سرو کې بل ټوپ تونل ته اشاره کوي، د ټوپونو شمېر تکرارېږي که نه، یو سایټ د پریفکس مالک دی، او تاسې ته هغه مدیریتي لار ده چې بدلون ته پاتې وي۔ که له پنځو څخه یو هم نامعلوم وي، نور څلور اټکلونه دي۔