OpenVPN-нің UDP жауабы неге дұрыс емес мекенжайдан шығады

OpenVPN клиенті бір мекенжайға қоңырау шалады, сервер басқа мекенжайдан жауап береді, ал туннель ешқашан көтерілмейді. Сервер журналы пакеттің келуін, ал жазу жауаптың шығуын көрсетеді, сондықтан қате клиентке жабылады. Бірнеше интерфейсі бар немесе бір интерфейсте бірнеше мекенжайы бар хостта екі тарап қай мекенжай пайдаланылып жатқаны туралы жай ғана келіспейді. Жауап IP деңгейінде дұрыс, алайда көптеген клиент бастауы өздері хабарласқан мекенжайға сай келмейтін датаграмманы тастап жібереді.

Бастау өзгергенде клиент нені көреді

Белгілі бір жергілікті мекенжайға байланбаған UDP сокетінің тұрақты бастауы болмайды, сондықтан ядро жіберу кезінде біреуін таңдайды. Бұл таңдау клиент мекенжайына қарай маршрут іздеуінен шығады, ал бастау іздеу таңдаған интерфейстің мекенжайы болады. Бір интерфейсі бар машинада таңдау көрінбейді; басқару мекенжайы, ашық мекенжай және сол желілік картадағы қосымша мекенжайы бар хостта ол маршрут метрикалары мен саясатына тәуелді. Саясатқа негізделген маршруттау сәйкессіздікті азайтпай, көбейтеді, өйткені ереже клиент ешқашан жетпеген жоғарғы арнаны таңдай алады. Бір провайдерден үйренген әдепкі маршрут пен екіншісіне сілтейтін бастау ережесі оны тудыруға жеткілікті.

Жауаптарды сүзетін клиенттер мен дәл төрттікті және бастауды күтетін қосылымды қадағалау жауапты пайдалы хабарламасыз тастайды. Сосын туннель ештеңе келмегендей уақыт бітіреді, сондықтан бұл клиент жағындағы firewall мәселесі деп қате саналады. Тек серверде алынған жазу қатені түсіндірудің орнына растайды, өйткені жауап шынымен шығады. Басқа нәрсені өзгертуден бұрын жауаптың бастауын клиент қоңырау шалған мекенжаймен салыстырыңыз.

multihome опциясы шын мәнінде не істейді

Директива конфигурация файлында multihome және пәрмен жолында --multihome түрінде жазылады және UDP серверін клиент пакеті жеткен мекенжайдан жауап беруге мәжбүр етеді. Ядро қабылдау кезінде бастапқы тағайындалған мекенжайды қосымша дерек ретінде береді, ал OpenVPN сол мәнді жауаптың бастауы ретінде пайдаланады. Осылайша, жалпы мекенжайды тыңдайтын сервер, IPv4 үшін local 0.0.0.0 немесе оның 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-ті жаңартпайды және бір мекенжай отбасын екіншісін қабылдауға мәжбүрлемейді. Бірнеше жоғарғы арнасы бар серверде әр бастау үшін қайтару жолы әдейі келісілуі керек, әйтпесе жауаптар клиент сүзгісі ешқашан рұқсат етпеген интерфейстен шығады. Сол сияқты, префикс өзгергеннен кейінгі жаңа мекенжай клиенттерге жетуі керек анықтау және қолдау көрсетілетін қайта қосылу ағыны арқылы, ескі жазба арқылы емес.

Сервер сәйкестігін тексерулер мен сертификаттарды растауды дәл қазіргі күйінде қалдырыңыз, өйткені өзгерген мекенжай расталмаған серіктесті қабылдауды ақтамайды. Егер жауап енді көзделген бастаудан шығып, туннель әлі де іске аспаса, бастау мәселесін шешілді деп санап, әрі қарай жүріңіз. Келесі байқалған қате маршруттауға, сүзуге немесе аутентификацияға жатады, ал тыңдаушыны қайта өзгерту оған жетпейді. Жауаптың бастауын билетте клиент қоңырау шалған мекенжайдың жанына жазыңыз, сонда келесі адам сол фактіні бір пәрменмен тексере алады.