WireGuard префикс домаћина: зашто једна адреса ради, а остале не
Адреса /32 на интерфејсу је исправан префикс домаћина и усмерава само ту адресу. Додајте руту коју AllowedIPs подразумева, а затим проверите повратни пут.
Тунел је активан, handshake се дешава свака два минута, и тачно једна адреса са друге стране одговара. Пингови на тунелску адресу peer-а раде; ништа иза ње не ради. Неко прочита конфигурацију интерфејса, види префикс домаћина и закључи да је маска погрешна. Проширење на /24 поправи пинг на неко време и затим поквари нешто друго. Префикс никада није био крив, а рута која је недостајала није она коју контролише маска.
Шта префикс интерфејса заправо ствара
На Linux-у додела адресе интерфејсу ствара повезану руту за тај префикс. Ако доделите префикс домаћина, повезана рута покрива једну адресу. Ако доделите /24, покрива њих 256, а свака од њих се сада сматра доступном преко те везе.
ip -4 addr show dev wg0
ip -4 route show dev wg0
ip route get 10.80.7.1
Префикс домаћина је потпуно нормалан избор за тунел од тачке до тачке, јер је на другом крају тачно један peer. Трећа команда је она која одговара на корисниково питање: говори који би интерфејс кернел користио за то одредиште, и неће показати ништа корисно ако се не подудара ниједна рута.
То је цело објашњење симптома. Једна адреса одговара јер за њу постоји повезана рута или зато што листа дозвољених peer-а случајно укључује. Све остало нема руту и одбацује се пре него што WireGuard уопште буде укључен. Тунел је цело време здрав, зато бројач handshake-а и даље изгледа смирујуће.
AllowedIPs су два правила под једним именом
Листа дозвољених по peer-у у WireGuard-у обавља два посла одједном, а синтакса конфигурације чини да изгледају као један. На улазу дозвољава које изворне адресе peer сме да представи. На излазу бира коме се peer-у пакет шаље, проналажењем најспецифичнијег поклапања.
Ниједан од тих послова није routing. Кернел још мора да одлучи да пакет припада интерфејсу тунела пре него што га WireGuard погледа, а та одлука долази из табеле усмеравања. Унос peer-а са широком листом дозвољених не инсталира сам руту.
Зато конфигурација може изгледати потпуна, а понашати се асиметрично. Клијент шаље на другу страну јер рута постоји, а одговори никада не долазе јер листа дозвољених друге стране не дозвољава извор клијента или зато што друга страна нема повратни пут. Оба смера су одвојене одлуке са одвојеним начинима квара. Записати који од њих тестирате је половина дијагнозе.
Одакле долази рута
Ако користите wg-quick, руте се генеришу за вас из листе дозвољених сваког peer-а, осим ако сте поставили Table = off и сами преузели контролу. То је понашање које алат документује, и то је разлог зашто конфигурација без изричитих директива рута ипак ради.
sudo wg show wg0 allowed-ips
ip route show | grep wg0
sudo wg-quick strip wg0
Упоредите листу дозвољених са рутама које заиста постоје. Peer који дозвољава целу подмрежу, али је створио само руту домаћина, значи да помоћник никада није покренут или да интерфејсом управљате директно помоћу wg и ip, и у том случају вам ништа не генерише руте.
Када њиме управљате ручно, рута је један ред и њен облик је изричит: одредиште кроз интерфејс, без приступне тачке јер је веза од тачке до тачке. Додавање није заобилазно решење за лош префикс; то је половина која недостаје у дизајну који је свесно преузео усмеравање.
Шири префикс не додаје унос peer-а
Примамљив поправак је променити адресу у /24 како би повезана рута покрила LAN сервера. Чини се да ради, а разлог зашто се чини да ради јесте то што се повезана рута сада подудара, а не то да је WireGuard научио нешто ново.
Оно што сте такође учинили јесте да цели распон присвојите као директно доступан преко те везе, укључујући адресе које припадају другим peer-овима или LAN-у који је заправо иза сервера. Саобраћај ка тим адресама сада улази у тунел, а да ли ће изаћи на другој страни зависи од усмеравања и листа дозвољених самог сервера.
Криптографска страна није захваћена ни у ком случају. WireGuard још треба унос на листи дозвољених који покрива одредиште да би изабрао peer-а, а друга страна још треба унос који покрива ваш извор да би га прихватила. Шири префикс интерфејса не може пружити ниједно од тога.
Потврдите оба смера пре него што било шта промените
Обрадите два краја одвојено и запишите шта сваки каже. На клијенту рута и унос peer-а; на серверу огледална слика плус његов сопствени повратни пут:
ip route get 192.168.70.20
sudo wg show wg0 allowed-ips
sudo wg show wg0 latest-handshakes
sudo tcpdump -ni wg0 -c 10
Снимак је оно што решава спорове о смеру. Ако се одлазни пакети појаве на интерфејсу тунела, а сервер ништа не бележи, удаљени крај их одбија, обично зато што је ваш извор изван његове листе дозвољених. Ако се не појави баш ништа, рута недостаје или показује негде другде.
Затим поправите ужи крај. Унос на листи дозвољених на страни сервера за адресу вашег клијента и унос на страни клијента за одредишну подмрежу уобичајен је облик и оставља префикс интерфејса на миру. Проширите префикс само ако план адреса заиста жели заједничку подмрежу на тој вези, и учините то као промену плана, а не као корак отклањања грешака.