Одговорот излегува преку LAN, а не преку тунелот: зошто и како

Услуга објавена преку порта работи од поголемиот дел од интернетот и не успева од една канцеларија. Некој го проверува тунелот, гледа дека барањето пристигнува и заклучува дека одговорот мора да се врати по истиот пат. Linux не работи така, и никакво проверување на тунелот нема да го промени одговорот. Одговорот се рутира според дестинацијата, а тој еден неуспешен повикувач се наоѓа во подмрежа до која домаќинот веќе стигнува директно.

Што всушност одлучува за излезен пакет

Јадрото бара рута за дестинацијата на пакетот, ги прегледува правилата на политиката по редослед на приоритет, а потоа табелата што ја избира соодветното правило. Интерфејсот преку кој пристигнал пакетот не игра никаква улога, освен ако не е напишано правило или ознака за да биде важно. Тоа е факт за рутирањето на овој домаќин, а не дефект во тунелот.

Затоа барање примено преку тунелот може да произведе одговор што излегува преку физичкиот интерфејс, и текот станува еднонасочен без ниту еден уред да пријави грешка. Проверете ги двата правци пред да донесете заклучок за тунелот. Одговор што излегува по погрешниот правец исчезнува од бројачите на тунелот, поради што двата краја не се согласуваат дали нешто било испратено. Забележете кој бројач се променил пред да допрете правило.

Зошто победува локалната подмрежа

Домаќин со адреса на локална мрежа има поврзана рута за тој префикс во главната табела, а поврзаната рута е директно совпаѓање. Кога повикувачот доаѓа од истата подмрежа, пребарувањето ја наоѓа локалната врска пред тунелот воопшто да се разгледа.

Асиметријата е она што ја прави дијагнозата збунувачка. Повикувачите од поширокиот интернет работат затоа што не се совпаѓаат со ниту една локална рута, додека единствениот повикувач што го дели канцеларискиот префикс не успева, а тоа е токму повикувачот со кој некој тестира.

Покриеноста на партнерите не е исто што и инсталирани рути

Од страната на тунелот, дозволените опсези на партнерот опишуваат што може да се испрати во тунелот и кои извори се прифаќаат од него. Тие не кажуваат ништо за тоа каде локалната табела за рутирање ќе испрати пакет.

Ако алатката за тунел инсталира стандардна рута на домаќинот, таа може да повлече неповрзан сообраќај во тунелот како колатерална штета. Таму каде што одлуката треба да ја носи правило на политиката, опцијата за инсталирање рути постои токму за да го спречи тоа, а адресите, клучевите и поставките на крајната точка остануваат точно како што беа. Стандардна рута додадена за удобност е вообичаен начин домаќинот да ја загуби сопствената локална мрежа.

Изберете ја табелата според адресата на изворот

Правило засновано на изворот ги испраќа одговорите од адресата на услугата во приватна табела чија стандардна вредност е тунелот, додека сето друго продолжува да ја користи главната табела. Изберете броеви на табела и приоритет што не се користат локално, и прочитајте ги постојните правила пред да вметнете нешто. Читајте ги живите правила наместо зачувана датотека, бидејќи двете можат да се разликуваат по рестартирање.

ip -6 route add default dev wg0 table 200
ip -6 rule add priority 32000 from 2001:db8:aa::20/128 lookup 200
ip -6 rule add priority 32001 from 2001:db8:aa::20/128 unreachable

Последниот ред прави отсутната рута видливо да не успее наместо да се врати на локалната врска. Изворот мора навистина да биде доделен на домаќинот, а обичните локални и главни пребарувања мора да останат на своите поранешни позиции. Правилото избира табела според изворот; тоа не споредува должини на префикси меѓу табелите.

Потврдете го патот, потоа услугата

Прашајте го јадрото што би направило наместо да заклучувате од снимка, користејќи ја адресата на услугата како селектор на извор. Погрешен одговор овде заштедува цело следење на пакети.

ip -6 route get 2001:db8:bb::30 from 2001:db8:aa::20

Излезот треба да го именува тунелот. Потоа тестирајте извор што не сте го допреле и потврдете дека тој уште ја зема локалната врска, така што промената остана ограничена на една адреса. Поширок селектор не би докажал ништо за првичната жалба.

Што ова не поправа

Оставете го проследувањето, правилата на огнениот ѕид и однесувањето на ICMPv6 на портата како што беа, зашто рутата по извор не заменува ниту едно од нив. Пораката Packet Too Big што недостасува уште ги крши големите одговори, без разлика која табела победила во пребарувањето. Поправете го тоа пред да додадете правила за рутирање, инаку симптомот ќе ја надживее промената.

Потврдете го моделот на објавување пред да примените било што од ова. Обратниот прокси што отвора сопствена backend врска го претставува сопствениот извор и не го зачувува повикувачот, затоа овој дефект не може да се појави во таков дизајн. Примената на правилото таму би додала исклучок во рутирањето што ништо не решава и ја крие вистинската причина.

На крајот, запишете ги броевите на правилата и табелата во управувањето со конфигурацијата на домаќинот. Правило на политиката додадено рачно исчезнува при следното повторно градење, а канцеларискиот повикувач се враќа со истата жалба.