mDNS преко WireGuard-а: три капије пре него што peer одговори
Avahi-ју је потребан одговарајући интерфејс, рута до групе и peer који поседује одредиште. Три капије, три одвојене провере и никакво гранање.
Постављање multicast заставице на WireGuard уређају чини интерфејс подобним за софтвер за откривање и то је све што заставица ради. Она не говори протоколу куда групни пакет треба да иде, а на уређају са неколико peer-ова нема једног очигледног одговора. Између демона који ради и откривене услуге стоје три одвојене капије.
Тестирајте их по реду, јер пролазак кроз једну не говори ништа о следећој.
Прва капија: заставица и политика демона
Linux WireGuard уређај се ствара као point-to-point веза без ARP-а и подразумевано не носи multicast заставицу. Додавање заставице је локална промена интерфејса коју изводи све што управља уређајем. Avahi има свој поглед на свет изнад тога, а његова подразумевана политика потпуно прескаче point-to-point интерфејсе. Зато се пре него што се помери и један пакет примењују два независна теста подобности.
Дакле, демону је потребна изричита одлука, а не само покренут процес. Његове документоване контроле укључују allow-interfaces, deny-interfaces и allow-point-to-point, а последња је поставка коју људи пропуштају.
Провере испод пријављују заставице везе, multicast руту и то да ли се конфигурација демона уопште парсира:
ip -d link show wg0
ip route get 224.0.0.251
avahi-daemon --checkДемон који је успешно покренут није нужно отворио сокете на интерфејсу који вас занима. Читајте његову ефективну конфигурацију уместо да претпостављате да је статус услуге једнак покривености.
Друга капија: рута до групе
Друга капија је обично рутирање. Пакет упућен на 224.0.0.251 следи табелу прослеђивања као и све друго, а ако га табела шаље кроз физички LAN интерфејс, никаква WireGuard конфигурација то неће променити. Прво поправите руту и остатак истраге постаје краћи. Погледајте шта језгро пријављује за групну адресу пре него што додирнете било које кључеве peer-а.
| Observation | Gate it belongs to | What it does not prove |
|---|---|---|
Multicast flag present on wg0 | Interface eligibility | The daemon will use the interface |
Route to the group via wg0 | Forwarding | Any peer will receive it |
| Destination inside a peer's allowed list | Peer selection | That peer's network will answer |
Без посебне руте језгро се враћа на сопствену multicast обраду везе, због чега подразумевано изгледа исправно на равној LAN мрежи, а погрешно чим исти групни саобраћај треба да изађе кроз тунел. Квар је тих са стране пошиљаоца: упит негде оде, а одговор никада не стигне.
Трећа капија: WireGuard бира један peer по пакету
WireGuard бира одлазни peer тражењем одредишта у скуповима дозвољених адреса, а Linux путања преноса обавља то тражење једном по пакету. Резултат је један и пакет се шифрује за тај peer. Исти групни префикс у дозвољеним листама више peer-ова не ствара чланство ни репликацију; ствара двосмислено тражење које се разрешава на једном од њих.
На наменској вези с два краја то је управо оно што желите, јер постоји један намеравани прималац за свесно пренесени групни саобраћај. На интерфејсу с пет peer-ова то је ограничење, а не карактеристика, и поправка припада дизајну, а не конфигурацији било ког појединачног peer-а.
Дизајн с гранањем захтева изричит релеј, одвојене везе или потпуно другачији механизам откривања. Објављивање рецепта за два краја као решења за много клијената зато што сваки клијент може да пинг-ује гејтвеј јесте начин да се то погрешно постави.
Долазни смер се проверава другачије: извор примљеног пакета мора да падне унутар дозвољене листе аутентификованог peer-а. Додавање multicast одредишта тамо не замењује стварно власништво извора пошиљаоца.
Одраз је граница, а не мост
Avahi рефлектор репродукује mDNS поруке између интерфејса које одабере, на апликационом слоју. То је граница откривања између мрежа, а не Ethernet мост и не општи multicast рутер. Два рефлектора повезана на исте мреже радо ће створити петљу поновљених објава.
Одраз такође предаје имена услуга и њихове метаподатке другој мрежи, што је одлука о приватности колико и одлука о рутирању. Ограничите одабране интерфејсе и користите филтере услуга где их инсталирана верзија подржава, како би границу прелазиле само објаве које овлашћени корисник треба.
Откривање и коришћење остају одвојени резултати. Клијент може да види објаву услуге чија је оглашена адреса недоступна с места на ком клијент јесте, или чија врата његова политика приступа одбија. Потврдите везу са услугом након што се објава појави, и ако апликација подржава стабилно DNS име или изричиту адресу сервера, дајте томе предност уместо проширења link-local откривања. Опис рутирања криптокључем покрива избор peer-а према одредишту на ком све ово почива.