OpenVPN работи дома, но не на една мрежа: UDP или TCP?

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

Која фаза не успеа покажува кое споредување е важно

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

Снимајте додека повторувате, а не потоа. На клиентот tcpdump -ni any udp port 1194 покажува дали воопшто се враќа одговор. Повторете го на WAN интерфејсот на сервер што го контролирате, што открива дали тие пакети воопшто стигнуваат до далечниот крај.

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

UDP филтрирање наспроти затворен порт

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

TCP профилот на портата 443 е вообичаеното решение, бидејќи наликува на обичен 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, во нивниот дел за напредна безбедност. Откако таа контрола е активна, серверот зад комутаторот не одговара никому и секој клиент истекува на ист начин. Нејзиното бришење и зачувувањето на тековната конфигурација е целата поправка, но само откако ќе утврдите дека комутаторот навистина е на патеката.

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

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

Преклопување на адреси што изгледа како DNS дефект

Пристапна мрежа нумерирана во 10.0.0.0/8 може да се преклопи со базенот на тунелот, а resolver-от обично живее во тој базен. Кога лаптопот добива адреса како 10.184.178.50 со /8 маска на Wi-Fi, секое одредиште 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, ако некогаш биде потребен.