Вгнезден WireGuard: средниот скок не може да одговори на сопствениот порт
Кога средниот скок ги праќа сите пакети во еден тунел, одговорите на неговата влезна услуга излегуваат по погрешниот пат. Правило за изворен порт на интерфејсот го поправа тоа.
Три WireGuard скока стигнуваат до мрежа без јавна адреса, а потоа средната машина престанува да одговара на портот на кој требаше да слуша. Тунелот понатаму продолжува да работи, далечниот домаќин продолжува да одговара, и само средниот сервер замолкна однадвор. Таа комбинација збунува токму затоа што е самопредизвикана: средниот скок ја почитува сопствената табела за рутирање, а табелата ги праќа неговите одговори во погрешна насока.
Синџир што работи додека не разговараш со средната кутија
Земете илустративен синџир: клиентот A стигнува до серверот B на UDP 500, а B продолжува до серверот C на UDP 500. C прима сообраќај само од адресата на својот единствен партнер, што го прави лист и го држи неговото однесување едноставно. B не е лист, и сите интересни работи за овој дефект се случуваат таму.
Разликата е важна затоа што улогите на лист и средина влечат во спротивни насоки. Листот може да ги прати сите пакети во еден тунел без последици, бидејќи ништо друго не зависи од него. Средниот скок е истовремено крајна точка за клиентите и клиент кон далечната страна, и тие две работи сакаат различно рутирање.
Зошто одговорот излегува низ тунелот
На B, интерфејсот кон C носи AllowedIPs = 0.0.0.0/0 заедно со соодветната стандардна рута. Затоа секој пакет што B го создава влегува во тој тунел, освен ако нешто поконкретно не добие предност.
Пакет од A адресиран до B пристигнува и се прифаќа, бидејќи B е дестинацијата и локалната испорака се случува прва. Одговорот е сосема нов локално создаден пакет насочен кон јавната адреса на A, и таа дестинација се совпаѓа со стандардната рута во тунелот. C го прима, не ја поседува таа адреса и го отфрла.
Симптомот се чита како проблем со огнен ѕид или несовпаѓање на клуч, и ниту едното не е точно тука. Снимен сообраќај на тунелот кон C покажува дека одговорите одат во погрешна насока. Тоа едно набљудување штеди повеќе време отколку било колку читање конфигурација, затоа запишете го пред да почнете да менувате клучеви. Секој што не ја видел снимката ќе претпостави дека самиот тунел е расипан.
Тесното поправање: правила за политика што се совпаѓаат со изворен порт
Одговорите од слушачкиот сокет на B излегуваат со изворен порт 500. Правило за политика може да се совпадне и да ги врати тие пакети во обичната табела:
ip rule add sport 500 table main priority 100
ip rule add sport 8080 table main priority 101Правилата за политика се разгледуваат по редослед на приоритет, а главната табела стои на 32766, па правило на 100 се прашува пред стандардната рута на тунелот да каже нешто. Додајте еден запис за секој порт што мора да остане достапен однадвор и ништо повеќе, за да продолжи пренесениот сообраќај да го користи тунелот за кој е изграден.
Знајте ја границата на овој трик. Селекторот sport се совпаѓа со локално создадени пакети, што точно го покрива случајот со одговорот и намерно не покрива сообраќај што B само го препраќа за некој друг. Услуга вгнездена зад B продолжува да бара свој одговор, а тврдењето спротивно дава поправка што работи за првата услуга и не успева за втората.
Дајте му сопственик на правилото
Правило внесено во командната линија исчезнува следниот пат кога интерфејсот ќе се изгради повторно. Во поставка на WireGuard, ставете го таму каде интерфејсот се создава и отстранува:
PostUp = ip rule add sport 500 table main priority 100
PostDown = ip rule del sport 500 table main priority 100Ако интерфејсот го поседува NetworkManager, кука од дистрибуцијата или влезна точка на контејнер, парот му припаѓа на тој сопственик, а не на рачно уредена датотека. Проверете ги ефективните правила по повторно поврзување, не само по првото стартување, бидејќи првото стартување е случајот што секогаш работи.
Споредете ги алтернативите чесно
Правилото за изворен порт е еден од четирите излези и најтесниот од нив. Има предност што воопшто не ја допира политиката на тунелот, поради што обично ги надживува подоцнежните промени. Тесните поправки исто така гласно паѓаат кога престануваат да важат, додека широкиот исклучок продолжува тивко да работи долго откако причината за него исчезнала. Таа разлика е поважна од елеганција кога по две години кутијата ја поседува некој друг.
| Approach | What it costs | Where it breaks |
|---|---|---|
| Source-port policy rule | One rule per exposed port | Anything B forwards rather than originates |
| Destination exception route | A route pinned to specific client addresses | Clients whose address changes |
| Stop full-tunnelling on B | Loses the catch-all path toward C | Designs that depend on it |
| Split into two tunnels | More interfaces and more policy | Nothing, at the cost of complexity |
Проверете од двата краја откако ќе изберете. Од A започнете врска кон портот на B и држете ја зафатена некое време. На B натерајте го јадрото да го оправда патот на одговорот со нешто како ip route get <address-of-A> sport 500, и потврдете дека го именува WAN интерфејсот, а не тунелот. Потоа проверете дека нешто зад C продолжува да одговара низ синџирот, што докажува дека исклучокот останал тесен наместо да се претвори во заобиколување. На крајот запишете ги портовите во белешките за дизајн, инаку следниот оператор ќе го открие ова повторно на друга услуга.