Том таталт ба VPN: замыг хүсэлтийн үед сонгоно

„Том таталтыг VPN-ийн гадуур явуул, жижиг хариуг түүн дээр байлга“ гэдэг нь чиглүүлэлтийн бодлого мэт сонсогддог ч тийм биш. Чиглүүлэгч тухайн мөчид боломжтой мэдээллээр шийддэг: хаяг, порт, протокол, firewall тэмдэг, тодорхойлсон урсгал. Хариуны эцсийн хэмжээ энэ олонлогт орохгүй, учир нь тэр хараахан ирээгүй, чиглүүлэгч байтуудыг хэмжих үед аль хэдийн тээж байна. Хэрэв даалгавараар чиглүүлэхийг хүсвэл шийдвэр даалгаврыг мэддэг цэг рүү шилжих ёстой бөгөөд доорх шалгах хуудас таны загварт ийм цэг байгаа эсэхийг харуулна.

Чиглүүлэгч хариуг хэмжиж чадахгүй байгаа шалтгаан

Багцад зам хэрэгтэй болсон мөчид чиглүүлэгч урсгалын хамгийн ихдээ эхний хэдэн багцыг харсан байдаг. Хэн хэнтэй ярьж байгаа, ямар протоколоор, ямар тэмдгээр, одоог хүртэл хэдэн байт өнгөрснийг хэлж чадна. Өнгөрсөн байтууд өнгөрсөн цагийг дүрсэлнэ. Хариуны хэмжээ нь хараахан үүсээгүй хариуны шинж чанар бөгөөд хуваагдсан эсвэл урсгалт хариунд урьдчилан хэзээ ч мэдэгдэхгүй байж болно.

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

Шалгалт 1: зам сонгож чадах шийдвэрийн цэг байна уу?

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

Хариу нь „гарц“ бол шалгах хуудас аль хэдийн бүтэлгүйтсэн. Гарц нь мэдэгдэх урсгалыг очих газар, тэмдэг эсвэл харилцагчийн сегментээр ангилж, эхний багцаас тодорхой замаар явуулж чаддаг нь зөвшөөрөгдсөн шинэчлэгчид ихэвчлэн хангалттай, харин үл мэдэгдэх хариуны хэмжээнд хэзээ ч хангалтгүй.

Шалгалт 2: мета өгөгдөл танд үнэхээр юу хэлж байна вэ?

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

Програмын мета өгөгдлийн дэмжиж чадах зүйл бол даалгаврын тухай шийдвэр: энэ ажлын урсгал бөөн синхрончлол, энэ нь интерактив, энэ нь мэдэгдэх эх сурвалжаас програм хангамжийн шинэчлэл. Энэ нь санааны хэлээр бичигдсэн бодлого бөгөөд туршихад хангалттай тогтвортой. „Энэ хариу дөчөөс дээш мегабайт байх болно“ бол тийм бодлого биш.

Шалгалт 3: урсгал аль хэдийн байна уу?

Урсгалын чиглүүлэлт холболтын таних тэмдгийг өөрчлөхгүйгээр өөрчлөгдөж болох бөгөөд энэ ялгааг зөв барих нь үнэ цэнэтэй. TCP холболт нь төгсгөлийн хаяг, портоор тодорхойлогддог бөгөөд чиглүүлэлтийн хүснэгт доор нь өөрчлөгдвөл багцууд өөр замаар явж болно. Нүдэнд үзэгдэхгүйгээр өөрчлөгдөж чадахгүй зүйл бол сүлжээний хаягийн хөрвүүлэлтийн төлөв: урсгалыг өөр гарц руу зөөх нь ихэвчлэн нийтийн эх үүсвэрийн кортежийг өөрчилдөг бөгөөд алслагдсан тал тохирох төлөвгүй өөр түншийг харах болно.

conntrack -L -p tcp --dport 443 | head -5
ip route get 203.0.113.10
ss -tn state established dst 203.0.113.10

Тиймээс практик дүрэм бол холболтын дунд нэг гарцаас нөгөө рүү зөөх нь шилжилт биш, шинэ харилцаа юм. Загвар нь ижил холболт үргэлжлэхийг шаарддаг бол шийдвэрийг эхний SYN-ээс өмнө гаргах ёстой байсан бөгөөд дараа нь нэмсэн ямар ч багцын дүрэм үүнийг цэвэрхэн сэргээж чадахгүй.

Шалгалт 4: жинхэнэ шаардлага гарц уу, хоцролт уу?

„Бөөн урсгалыг өөр тийш явуул“ гэсэн олон хүсэлт нь үнэндээ том шилжүүлэг интерактив ажлыг удаан мэт мэдрүүлдэг гэсэн гомдол юм. Энэ нь хуваарийн асуудал бөгөөд хуваарийн хариулт бий: одоогийн зам дээрх шударга дараалал эсвэл дэмжигдсэн зурвасын өргөний бодлого нь бөөн урсгалыг чатын мессежийг өлсгөхөөс хамгаална, хоёуланг нь хөдөлгөхгүйгээр.

tc qdisc replace dev eth0 root cake bandwidth 100mbit

Шинж тэмдгийг ингэж шийдэх нь гарцын шийдвэрийг аюулгүй байдлын бодлого тавьсан газарт нь үлдээж, нэг командаар буцаах боломжтой. Бүхэл урсгалын ангилалд гарцыг өөрчлөх нь баталгаажуулалт, бүртгэл, хандалтын дүрэмд нөлөөлөх бодлогын өөрчлөлт тул хоцролтын гомдолд эхний хэрэгсэл байх ёсгүй.

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

Шалгах хуудсыг өөрчлөлтийн бүртгэлд хадгал: шийдвэрийн цэг, түүнийг хөдөлгөдөг талбар эсвэл даалгавар, урсгал аль хэдийн байгаа эсэх, хэмжсэн шинж тэмдэг хоцролт уу эсвэл гарц уу. Дөрвөн асуулт, мөн дөрөвийн хариулдаг бодлого бол хамгаалах биш ажиллуулж болох бодлого юм.