VPN-ийн маршрутын кэш таны өөрчлөлтийг нууж байна уу? Гурван зүйлийг шалгаарай

Өөрчлөлт хүчин төгөлдөр болохгүй үед маршрутын кэшийг цэвэрлэх нь эхний зөн совин боловч орчин үеийн Linux-д энэ нь дэмий хөдөлмөр: глобал IPv4 маршрутын кэшийг олон жилийн өмнө устгасан тул ip route show cache юу ч хэвлэхгүй бөгөөд цэвэрлэх зүйл байхгүй. Таныг хуурч буй төлөв нэг давхарга дээр амьдардаг: socket дотор, NAT зураглалд, resolver-д эсвэл хуучин профайлыг дахин хэрэглэсэн сүлжээний менежерт. Гурван асуулт эдгээр тохиолдлыг ялгана: буруу зам шинэ урсгалаас ирж байна уу эсвэл хуучин холболтоос, таны платформ маршрутуудыг огт кэшлэдэг үү, төлөв нь маршрутлалтад байна уу эсвэл түүний дээр байна уу. Интерфэйсийг дахин тохируулахын өмнө тэдгээрт хариулах хэрэгтэй.

Нэгдүгээр шалгалт: хуучин зам шинэ урсгалаас ирж байна уу?

Тогтоосон холболт өөрийг нь үүсгэсэн маршрутыг хадгалдаг. Тиймээс туннелээр дамжсан SSH сесс маршрутын хүснэгтийн өөрчлөлтийг даван туулж, шинэ сесс тэр даруй шинэ замыг авдаг, мөн «өөрчлөлт юу ч хийсэнгүй» гэдэг нь ихэвчлэн «хуучин socket үүнийг одоо ч барьж байна» гэсэн үг. Аль хэдийн нээлттэй байгаа цонхыг биш, шинэ процессоор туршиж үзээрэй.

ss -tnp | head
ip route get 1.1.1.1
curl -m 5 -sS -o /dev/null -w '%{remote_ip}
' https://example.com

Сүүлчийн команд нь шинэ холболт бодитоор хүрсэн хаягийг хэвлэдэг бөгөөд энэ нь статусын цонхонд итгэхгүйгээр бодит замыг харах хамгийн хямд арга юм. Үүнийг namespace эсвэл интерфэйс ашиглах ёстой байсан эх хаягтай харьцуул.

Шинэ урсгал зөв замыг авч, хуучин нь сэргэхгүй бол маршрутлалтыг харахаа зогсоо. Маршрут зөв байсан; сесс хуучин байсан.

Хоёрдугаар шалгалт: таны платформ маршрутын кэшийг огт хадгалдаг уу?

Linux-д хариулт нь үгүй, ихэнх гарын авлага үүнийг хэлдэг утгаар. Хаях глобал очих газрын кэш байхгүй, сонгосон маршрутыг барьдаг socket түвшний бичлэг socket-тай хамт чөлөөлөгддөг. ip-route гарын авлагын кэшийн хэсэг түүхэн зан төлөвийг дүрсэлдэг, одоогийн цөмд цэвэрлэж болох зүйлийг биш.

Бусад платформ өөр, зөвлөгөөг хуулах нь яг энд буруу болдог. Windows очих газрын кэш хадгалдаг бөгөөд үүнийг netsh interface ip delete destinationcache-оор цэвэрлэж болно. BSD болон macOS route -n get-аар очих газар бүрийн хайлтыг харуулдаг бөгөөд тэдгээрийн кэш өөрийн хуваарийн дагуу дуусдаг. Эдгээрийн аль нэг дээр ажилладаг команд Linux-д огт юу ч хийдэггүй, тиймээс ижил засвар туршиж буй хүмүүсийн тал хувьд бүтэлгүй мэт санагддаг.

NAT эсвэл conntrack хүснэгт нь маршрутын кэш биш боловч ижил шинж тэмдэг үүсгэдэг. Таны өөрчлөлтөөс өмнө орчуулагдсан урсгал өөрийн орчуулгыг хадгалж, маршрутлалтын бодлого урагшилсны дараа ч conntrack -L үүнийг удаан харуулна. Энэ нь хуучирсан төлөв боловч маршрутыг цэвэрлэх нь түүнд хүрэхгүй.

Гуравдугаар шалгалт: төлөв маршрутлалтад байна уу, эсвэл түүний дээр байна уу?

Өөр юу ч уншихын өмнө одоогийн хайлтыг уншаарай: очих газарт ip route get, дараа нь from болон эх хаягтай ижил команд, дараа нь ip rule show. Эдгээр гурав таны зорьсонтой нийцвэл маршрутлалт засах давхарга биш бөгөөд хуучирсан ажиглалт өөр газраас ирсэн.

Гурван түгээмэл сэжигтэн маршрутлалтын дээр суудаг. Сүлжээний менежер таны устгаснаас хэдхэн секундын дараа хадгалсан профайлаас маршрутыг дахин суулгаж болох тул өөрчлөлт буцаж байгаа мэт харагдана; хүснэгтийг дахин засахаас өмнө nmcli connection show --active болон unit-ийн төлөвийг шалгаарай. Resolver-ийн кэш хуучин хаягийг буцаадаг бөгөөд кэшийг тойрдог хэрэгслээр ижил нэрийг асуух хүртэл энэ нь маршрутлалтын алдаа мэт харагдана. Программын холболтын сан хуучин очих газар руу ажиллаж буй socket-ыг хадгалдаг бөгөөд цөмөөс хэзээ ч шинэ шийдвэр асуудаггүй.

Гурван хариулт ямар дүгнэлт хийх боломж олгодог

Хариултуудыг нэгтгэ, засвар ихэвчлэн өөрөө хэлдэг. Маршрутын кэшгүй платформ дээр шинэ урсгал буруу замыг авбал бодлого үнэхээр буруу гэсэн үг, тиймээс туннелийн суулгасан дүрэм, хүснэгтийг уншаарай. Хуучин сесс гацаж байхад шинэ урсгал зөв замыг авбал асуудал программ эсвэл socket-д байна. Хоёр тохиолдолд зөв маршруттай боловч ажиглалт эвдэрсэн бол төлөв маршрутлалтын дээр байна.

Ерөнхий шинэчлэлтэд эсэргүүц. Сүлжээний стекийг дахин эхлүүлэх эсвэл өгөгдмөл маршрут нь туннел байдаг машинд бүх маршрутыг устгах нь үүнийг засахад ашиглаж буй холболтыг тасалж болзошгүй бөгөөд аль давхарга бүтэлгүйтсэнийг хэлэх нотолгоог устгана.

Хэрэв үнэхээр ямар нэг зүйлийг цэвэрлэх шаардлагатай бол оношилгоонд тохирох хамгийн жижиг зүйлийг цэвэрлэ: нэг процессын socket-ууд, нэг conntrack бичлэг, resolver-ийн кэш. Дараа нь ижил шинэ урсгалын туршилтыг давтаж, юу өөрчлөгдсөнийг бичээрэй.

Тэмдэглэлдээ гурван төлөвийг тусад нь хадгал

Хадгалсан тохиргоо, одоогийн хайлт, ажигласан урсгал нь гурван өөр баримт бөгөөд тэдгээрийг «кэш» болгон нэгтгэх нь алдааг дахин гаргахад хүндрэлтэй болгодог. Маршрутыг эзэмшдэг профайл эсвэл unit, ip route get-ийн гаралт, бодит холболтын эх ба очих газрыг бичээрэй.

Тэдний хажууд платформ болон клиентийн хувилбарыг бичээрэй, учир нь Windows-ийн очих газрын кэшийг цэвэрлэх засвар Linux хостод хамаарах засвар биш бөгөөд хоёрын хооронд хуулагдсан журам буруу сургамж өгдөг. Асуудлыг өөр хүнд даалгахдаа тэдгээр гурван мөр таамаглахын оронд бүтэлгүйтсэн төлөвийг дахин гаргах боломж олгоно.