Chromecast ба DLNA илрүүлэлт нь чиглүүлэгдсэн VPN-ээр хэзээ ч гарахгүй

Кастлах товч юу ч харуулахгүй, VLC DLNA хоосон хэвээр байх ба нөгөө захын машин гомдолгүйгээр ping-д хариулдаг. Энэ хослол нь зурвасын өргөний асуудал ч биш, галт ханын нууц ч биш. Эдгээр протоколын илрүүлэлт нь локал сегмент дээрх бүлгийн солилцоо бөгөөд чиглүүлэгдсэн туннель бүлгийн хаягтай трафикийг зөөдөггүй. Таны эхлүүлэх гэж буй сесс хэзээ ч санал бологдохгүй.

Хүртээмж нь зүгээр. Илрүүлэлт дутуу байна.

Домог: туннельд тохиргоо эсвэл илүү багтаамж хэрэгтэй

Ердийн саналууд бол peer-to-peer трафикийг идэвхжүүлэх, MTU-г өсгөх, эсвэл туннелийн төхөөрөмжийн төрлийг өөрчлөх юм. Аль нь ч нэвтрүүлгийн домэйн нэмэхгүй. Multicast-ыг свитч болон локал сүлжээний стек хүргэдэг бөгөөд цэгээс цэг рүү TUN интерфейсд дүүргэх бүлгийн хаяг байхгүй.

Тохиргоог өөрчлөх нь алдааг илүү чанга болгож болно. Гэхдээ протокол хэзээ ч илгээгээгүй зарлалыг тэр гаргаж чадахгүй.

Илрүүлэлтийн солилцоо үнэндээ юу вэ

Таны таарах бараг бүх зүйлийг гурван загвар хамарна. mDNS нь 224.0.0.251 руу UDP 5353-аар илгээдэг, SSDP нь 239.255.255.250 руу UDP 1900-аар илгээдэг, хуучин SMB хөтлөлтийн жагсаалт дэд сүлжээний нэвтрүүлгийн хаяг руу явдаг байв. Тус бүр нь хост руу бус бүлэг рүү хаяглагддаг бөгөөд тус бүр нь ижил сегмент дээр сонсогчийг хүлээдэг. Чиглүүлэгдсэн туннелийн цаанаах хүлээн авагч тэр сегмент дээр байхгүй тул юу ч ирэхгүй.

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

Туннелийг өөрчлөхийн өмнө бичлэгийг уншина уу

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

Хоёр минутын бичлэг портын тухай нэг цагийн таамаглалыг орлуулна: tcpdump -ni tun0 udp port 5353 or udp port 1900.

Гурван шийдэл, хамгийн хямд нь эхэндээ

Клиентийг шууд үйлчилгээний хаяг руу чиглүүл. DLNA, SMB болон энгийн медиа серверүүдийн хувьд энэ нь илрүүлэлтийг бүрэн алгасаж, ачааны зам ажиллаж байгааг баталдаг тул хамгийн сайн эхний туршилт болоод ашиглахуйц тойрч гарах зам болдог. Chromecast нь үл хамаарах, учир нь хүлээн авагч хаяглагдахаас илүү олддог байхыг хүлээдэг.

Протоколыг гарц дээр дамжуул. mDNS тусгагч туннель болон LAN хооронд зарлалыг давтаж, Avahi нь тодорхой интерфейсийн жагсаалт авдаг тусгагч хэсгийг нийлүүлдэг. Дамжуулалтыг нарийн байлгаж, зарласан хаяг хоёр талаас хүртээмжтэй эсэхийг батал, тэгэхгүй бол хариулт нь үзэгч чиглүүлж чадахгүй дэд сүлжээ рүү заасан хэвээр байна.

Чиглүүлэхийн оронд гүүр хий. Сервер tap төхөөрөмжийг LAN руу гүүрдэх TAP сегмент нь хоёр төгсгөлийг нэг нэвтрүүлгийн домэйнд байрлуулдаг тул зарлалууд өөрчлөгдөлгүй гардаг. Энэ нь хамгийн үнэтэй сонголт ч юм, учир нь нэг дэд сүлжээ нь нэг алдааны домэйн гэсэн үг бөгөөд LAN дахь бүх multicast үйлчилгээ одоо бүх түнш рүү хүрдэг.

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

Гүүргүйгээр dev tun-ээс dev tap руу солих нь чиглүүлэгдсэн хэвээр TAP төхөөрөмжийг үлдээдэг тул зан төлөв өөрчлөгдөхгүй. client-to-client нь түншүүдийн хоорондын unicast-ыг зөвшөөрдөг бөгөөд нэвтрүүлгийг дүүргэдэггүй. Илрүүлэлтийн портыг нэг хост руу дамжуулах нь бүлгийн хаягтай трафикийг хүргэхгүй. Нэг хаягт уягдсан медиа сервер өөрийн тохиргоо VPN интерфейсийг жагсаах хүртэл тэр хаяг дээр хариулсаар байна.

Нэг шууд unicast хүсэлт, дараа нь нэг зарласан хүсэлтийг туршиж үзээрэй. Эхнийх ажиллаж, хоёр дахь нь ажиллахгүй бол туннель эрүүл бөгөөд илрүүлэлт нь бүх асуудал юм.