Зашто 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 и не чини да једна адресна породица прихвати другу. На серверу са више горњих веза повратни пут за сваки извор мора свесно да се договори, иначе одговори излазе кроз интерфејс који филтер клијента никада није дозволио. Исто тако, нова адреса после промене префикса мора да стигне до клијената кроз откривање и подржани ток поновног повезивања, а не кроз стари запис.

Оставите провере идентитета сервера и верификацију сертификата тачно онаквима какви јесу, јер измењена адреса не оправдава прихватање непровереног партнера. Ако одговор сада излази са предвиђеног извора, а тунел и даље не ради, сматрајте проблем извора решеним и идите даље. Следећа уочена грешка припада рутирању, филтрирању или аутентификацији, и још једна промена слушаоца је неће достићи. Упишите извор одговора у тикет поред адресе коју је клијент бирао, да би следећа особа могла да провери исту чињеницу једном командом.