OpenVPN үйдө иштейт, бирок бир тармакта иштебейт: UDP же TCP?
Бир тармак туннелди блоктойт, экинчиси блоктобойт. UDP фильтрлөө, коммутатордун flood коргоосу, TCP 443 камдык жолу жана дарек планынын кагылышын салыштырыңыз.
Ошол эле профиль үйдөн туташат, ал эми мейманкана, кампус же филиал тармагында токтоп калат. Күбөлүктөр өзгөргөн жок, ошондуктан кызыктуу өзгөрмө — жол: OpenVPN пакеттерди окуганга чейин алар менен эмне болот. Төрт ыктымал себепти текшерүүгө боло турган тартипте салыштыруу сертификаттар тууралуу божомолдоодон артык. Ар бири башка из калтырат, ал эми из аларды ажыратат.
Кайсы баскыч ийгиликсиз болгону кайсы салыштыруу маанилүү экенин көрсөтөт
Клиент журналы каякка жеткениңизди эбак жазып койгон. TLS ачкыч сүйлөшүүсү убакыт чегинде болбоду деген сап биринчи пакет чыкканын, бирок пайдалуу жооп кайтпаганын билдирет, бул жолду көрсөтөт. Сертификаттан баш тартуу такыр башкача көрүнөт: жооп келет, анан белгилүү текшерүү катасы себебин атайт. Кайталоо циклинин алдындагы акыркы сапты жазып алыңыз, анткени тармактар арасында салыштыра турган маани — ошол.
Кармоону кийин эмес, кайталап жатканда жасаңыз. Клиентте tcpdump -ni any udp port 1194 жооптун такыр кайтарыларын көрсөтөт. Аны өзүңүз көзөмөлдөгөн сервердин WAN интерфейсинде кайталаңыз — бул пакеттердин алыс четке такыр жетерин ачат.
Бир тараптуу трафик — бул жерде жеткиликтүү эң пайдалуу натыйжа, анткени ал үзгүлтүктүү нааразычылыкты иликтөө багытына айландырат. Кармоо файлдарын сактаңыз, анткени ошол эле маселе тууралуу кийинки билдирүүнү сүрөттөмө менен эмес, далил менен жабуу оңоюраак.
UDP фильтрлөө жабык портко каршы
Көптөгөн кирүү тармактары узак UDP'ни шектүү деп эсептейт, айрым ISP'лер аларга кошулат. Жабык порт клиент тарабынан ошол эле тынчтыкты жаратат. Айырма — тандалмалуулук: фильтр кайсы багыттарды же портторду таштаарына тандамал, ал эми жабык порт ошол портко багытталгандын баарын четке кагат.
443 портундагы TCP профили адаттагы чечим, анткени ал кадимки HTTPS агымына окшош жана көптөгөн captive порталдар менен чыгуу фильтрлеринен өтөт. Эки шарт аткарылышы керек. Сервер proto tcp-server менен угуусу керек, клиент proto tcp-client менен дал келиши керек, ал эми оператор ошол альтернативалык эндпоинтти жарыялашы керек. Иштеп жаткан UDP профилин TCP 443 деп кайра жазуу, алдыда эч ким укпаса, эч натыйжа бербейт.
Жабык порт — цензура эмес, конфигурация маселеси. Үй маршрутизаторунун артындагы серверге UDP портун багыттоо керек, ал эми маршрутизатордун брандмауэри ага уруксат бериши керек. Портко эч качан уруксат берилбесе, күбөлүктөргө карабастан ар бир клиент сүйлөшүүдө ийгиликсиз болот, ал эми бузулуу тармакка эмес, серверге ээрчийт.
Эски протоколдор бул өлчөмдө начар көрүнөт. PPTP'ге TCP 1723 плюс GRE керек, ал эми GRE — порт эмес, IP протоколу 47, ошондуктан кадимки порт багыттоо аны билдире албайт.
Пакеттерди коммутатор таштап жатканда
Башкарылуучу коммутатор туннелди атайын таштай алат. Айрым HPE жана Aruba моделдери кеңейтилген коопсуздук бөлүмүндө UDP flood коргоо көзөмөлүн сунуштайт, кээде Prevent UDP Blat Attack деп белгиленет. Ошол көзөмөл активдүү болгондо, коммутатордун артындагы сервер эч нерсеге жооп бербейт жана ар бир клиент бирдей убакыттан өтөт. Аны өчүрүп, иштеп жаткан конфигурацияны сактоо — бүт оңдоо, бирок коммутатор чындыгында жолдо экенин аныктагандан кийин гана.
Каршы далил — коммутатордун таштоосун провайдердин блогунан ажыратат. ISP менен билет ачпас мурун интерфейс эсептегичтерин жана flood коргоо журналын окуңуз. DoS же flood коргоосу бар керектөөчү маршрутизаторлор да ушундай формада ийгиликсиз болот, UDP бош туруу чеги кыска болгон каалаган ортоңку түзмөк да ошондой. Эч качан бүтпөгөн кол алышуу таштоону болжолдойт, ал эми бир нече мүнөт тынчтыктан кийин өлгөн туннель чекти болжолдойт.
Профилди өзгөртүүдөн мурун клиент менен сервердин ортосундагы ар бир түзмөктү жазып чыгыңыз. Туура эмес катмарга колдонулган оңдоо кийинки тармакка чейин туура көрүнөт. Бул тизме кийинки инженерге бүт иликтөөнү кайталабастан кайда кароо керектигин да айтат.
DNS бузулушуна окшош дарек капталышы
10.0.0.0/8 ичинде номурланган кирүү тармагы туннель пулу менен капталышы мүмкүн, ал эми resolver адатта ошол пулдун ичинде болот. Ноутбук Wi-Fi'де 10.184.178.50 сыяктуу даректи /8 маскасы менен алганда, ар бир 10.x багыты аныктама боюнча жергиликтүү. 10.4.0.1 үчүн пакеттер андан кийин LAN'га кетет, туннель иштеп турат, ал эми аттарды чечүү ийгиликсиз болот.
ip addr капталышты бир караштак ачат, ал эми ip route get 10.4.0.1 пакеттин чындыгында кайда жеткирилерин көрсөтөт. Көрүнүп турган симптом resolver бузулушу болгондуктан, бул бир нече DNS өзгөртүүдөн кийин да көп сакталып калат.
Пулду кайра номурлаңыз же ошол кирүү тармагын камтуудан тышкаркы кылып кармаңыз. Клиент тараптагы эч бир жөндөө капталыштан калыбына келтирбейт.
TCP камдык жолу менен жолду оңдоонун ортосунда тандоо
Жолду көзөмөлдөбөсөңүз жана колдонуучулар бүгүн иштеши керек болсо, TCP камдык жолун тандаңыз жана анын чыгымдарын кабыл алыңыз: TCP ичиндеги TCP жоготуу бар линияларда начар жүрөт, ал эми камдык жолго өзүңүз башкарган listener керек. Блок өз инфраструктураңызда болсо, жолду оңдоону тандаңыз, анткени брандмауэр эрежеси экинчи listenerден арзан. Кандай болбосун, катмарларды ирети менен өтүңүз: байланыш, сырткы транспорт, сүйлөшүү, ички маршруттоо. Ошол тармакта ийгиликсиз болгон баскыч — маанилүү жалгыз факт.
Натыйжаны колдонуучу боюнча эмес, тармак боюнча жазыңыз. Ошол эле бузулуу тууралуу кийинки билдирүү андан кийин сертификат теориясынан эмес, белгилүү баскычтан башталат. Бул жазуу качандыр бир керек болсо, туруктуу экинчи listenerди да негиздейт.