Зошто UDP одговорот на OpenVPN излегува од погрешна адреса

OpenVPN клиент избира една адреса, серверот одговара од друга, и тунелот никогаш не се крева. Серверскиот дневник покажува дека пакетот пристигнува, а снимката покажува одговор што излегува, затоа грешката му се припишува на клиентот. На домаќин со неколку интерфејси, или неколку адреси на еден интерфејс, двете страни едноставно не се согласуваат која адреса се користи. Одговорот е валиден на IP слојот, но многу клиенти отфрлаат датаграм чиј извор не е адресата со која стапиле во контакт.

Што гледа клиентот кога изворот се менува

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

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

Што всушност прави опцијата multihome

Директивата се пишува како multihome во конфигурациската датотека и како --multihome на командната линија, и таа го тера UDP серверот да одговара од адресата до која стигнал пакетот на клиентот. Јадрото при примање ја доставува оригиналната целна адреса како дополнителни податоци, а OpenVPN ја користи таа вредност како извор на одговорот. Така серверот што слуша на општа адреса, local 0.0.0.0 за IPv4 или неговиот IPv6 еквивалент, се однесува како секој клиент да стигнал до посебен слушател. Клиентите што влегле преку јавната адреса добиваат одговори од јавната адреса, а клиентите на внатрешна адреса од таа адреса. Ништо друго на патеката на пакетот не се движи: маршрутата, правилата за филтрирање и конфигурацијата на тунелот остануваат точно такви какви што биле.

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

Кога фиксната локална адреса е погрешна стандардна вредност

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

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

Докажете го изворот на одговорот однадвор

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

tcpdump -ni any udp port 1194
ss -lunp 'sport = :1194'
ip route get 203.0.113.10 from 198.51.100.20

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

Маршрутирањето, откривањето и филтрирањето остануваат одделни

Зачувувањето на изворот на одговорот не поставува излезна маршрута, не го ажурира динамичниот DNS и не прави едното семејство адреси да го прифати другото. На сервер со неколку горни врски повратната патека за секој извор мора свесно да се договори, инаку одговорите излегуваат низ интерфејс што филтерот на клиентот никогаш не го дозволил. Исто така, новата адреса по промена на префиксот мора да стигне до клиентите преку откривање и поддржаниот тек на повторно поврзување, а не преку стариот запис.

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