OpenVPN дээгүүр SSM: нэг эх үүсвэр ба бүлгийг эхнээс дуустал хянах

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

Эхлээд эх үүсвэр, бүлэг, хүлээн авагчийг тогтоо

Аль ч төхөөрөмжид хүрэхээс өмнө гурван утгыг бич: илгээх эх үүсвэрийн хаяг, хүлээн авагч нэгдэх бүлгийн хаяг, хүлээн авагч байрлах дэд сүлжээ. Жишээ IPv4 урсгалын хувьд 10.50.0.10 эх үүсвэр ба 232.20.30.40 бүлэг нь эх үүсвэрт онцлог загварт тохирох хосын төрөл юм. Эдгээр гурван утгаас илүү бүрхэг зүйлийг шалгах боломжгүй.

232/8 хүрээ нь эх үүсвэрт онцлог multicast-д зориулагдсан бөгөөд загварыг RFC 4607 баримт бичигт тайлбарласан. Хэрэв та SSM ажиллуулж байна гэж бодож байхдаа таны бүлэг тэр хүрээнээс гадуур байвал зогсоод байрлуулалт үнэхээр юу зорьж байгааг баталгаажуул, учир нь хүлээн авагчийн нэгдэл ба чиглүүлэгчийн дамжуулах шийдвэр хоёулаа загвар тогтвортой байхаас хамаарна.

Хүлээн авагч эх үүсвэрт нэгдсэн эсэхийг шалга

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

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

ip maddr show dev eth0
cat /proc/net/igmp | sed -n '1,40p'

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

Туннелийг харахаасаа өмнө буцах замыг шалга

Multicast чиглүүлэлт буцах замын шалгалт хийдэг бөгөөд unicast маршрут заасан интерфэйсээс өөр интерфэйсээр ирсэн пакетыг хаядаг. Энэ нь тодорхой илгээгдэж буй урсгал дараагийн хопт хэзээ ч хүрдэггүйн хамгийн түгээмэл шалтгаан бөгөөд аппликейшны түвшинд ямар ч ашигтай алдаа гаргадаггүй.

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

Дараа нь эх үүсвэрийн TTL таны зохиосон чиглүүлэгдсэн хопыг даван туулахад хангалттай том эсэхийг баталгаажуул. Эхний чиглүүлэгч дээр ажиллаад хоёрдугаарт үхдэг урсгал нь ихэвчлэн TTL-ийн асуудал, бодлогын асуудал биш.

Тохиргооноос илүү цөмийн multicast төлвийг унш

Тохиргоо таны юу хүссэнийг хэлнэ; цөм юу болж байгааг хэлнэ. Linux хоп бүр дээр multicast чиглүүлэлтийн бичлэгүүдийг уншиж, эх үүсвэр ба бүлгийн яг хосын хувьд ирж, гарч буй интерфэйсүүдийн жагсаалт байгааг баталгаажуул. Бүлэгт зориулсан бүх нийтийн эх үүсвэртэй бичлэг нь өөр объект бөгөөд эх үүсвэрт онцлог урсгалыг тайлбарлахгүй.

ip mroute show from 10.50.0.10 iif eth1
ip route get 10.50.0.10

Чиглүүлэлтийн демонууд тэр төлөв дээр өөрийн харцыг хадгалдаг бөгөөд түүнийг хэвлэх команд нь аль хэрэгжүүлэлт суусан эсэхээс хамаарна. Зарчим тогтмол: демоноос хосын дээд урсгалын бичлэгийг асууж, дараа нь цөмөөс дамжуулалтын бичлэг байгаа эсэхийг асуу. Цөмд бичлэг байхгүй байтал дамжуулж байна гэж бодож буй демон нь тэр хост дээрх тохиргооны хамрах хүрээний асуудал юм.

Хоёр нь санал нийлэхгүй бол VPN-г биш хостыг зас. Таны асуусан урсгалыг дамжуулж чадахгүй байгаа хопыг доорх юу ч нөхөж чадахгүй. Урсгал ажиллаж байх үед хоп бүрийн хос, ирж буй интерфэйс, гарч буй жагсаалтыг бич. Тэр бичлэг дараагийн доголдлыг шинэ мөрдөн байцаалт биш харьцуулалт болгоно.

Туннель үнэхээр хэрхэн хуулбарладаг вэ гэдгийг шийд

Энд VPN дээгүүрх multicast өдөр тутмын ажил байхаа болино. Цэгээс цэг рүү туннель пакетыг нөгөө талын цорын ганц хамтрагчид хүргэдэг тул хуулбар яг нэг клиентэд хүрдэг. Гүүрээр холбосон сегмент хуваалцсан холбоос мэт илүү ажилладаг, учир нь туннель хүрээг зөөдөг, гүүр юуг үерлэхийг шийддэг. Эдгээр нь өөр өөр хүргэх загварууд бөгөөд эхнийхийг ажиллуулж байхдаа хоёр дахь гэж үздэг загвар нэг хүлээн авагчид ажиллаж байгаа мэт харагдаж, дараагийнханд бүтэлгүйтнэ.

Олон цэгт серверээр дамжуулан нэгээс олон хүлээн авагчид хуулбарлалтыг тодорхой зохиох ёстой. Гарц дээр multicast маршрут суулгах нь VPN серверт аль хамтрагчид хуулбар авах ёстойг заадаггүй бөгөөд клиентийн талын ямар ч маршрут энэ шийдвэрийг түүний оронд гаргахгүй. Шаардлага олон хүлээн авагч бол дэмжигдсэн хуулбарлалт эсвэл санаатай сонгосон хувилбарыг ашиглаж, алийг нь сонгосноо бич.

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