Зошто зад истиот рутер се поврзува само еден VPN клиент

Два преносни компјутери стојат на истата домашна мрежа, а канцеларискиот VPN прифаќа точно еден од нив. Вториот или чека до истекот на времето или чека додека првиот не се исклучи, и никој не допрел поставка на клиентот меѓу двата обиди. Податоците за најава се истите што работеа пред една минута, и тоа е трагата дека автентикацијата не е дефектот. Три механизми го создаваат овој образец, а дневникот на самиот сервер кажува со кој се соочувате.

Прочитајте го дневникот на портата пред да допрете клиент

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

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

Запишете го исходот пред да промените нешто, бидејќи трите исходи од дневникот водат кон три неповрзани поправки. Белешка што именува кој од трите сте го виделе вреди повеќе од слика од екранот со грешка на клиентот.

Што прави рутерот со GRE и NAT-T

PPTP е класичниот виновник: контролниот канал е TCP 1723, а патеката на податоци е GRE, IP протокол 47. Многу потрошувачки рутери доаѓаат со PPTP помошник што следи една контролна врска, па вториот клиент зад истиот NAT ја отвора својата контролна врска и потоа воопшто не добива патека на податоци. Пренасочување на TCP порта со број 47 не прави ништо за GRE, бидејќи GRE е број на протокол, а не порта.

L2TP врз IPsec се однесува поинаку по дизајн: IKE користи UDP 500, NAT преминот го пренесува заштитениот товар на UDP 4500, а инкапсулацијата постои токму за да можат неколку клиенти зад една адреса да стигнат до истата порта. Тој дизајн не спречува порта или посреднички уред да наметне граница на сесии по адреса, а од каучот двата дефекти изгледаат исто. Сопствениот протокол на SoftEther има иста класа на проблем: рутер без работно пропуштање го пушта првиот клиент од локалната мрежа и го отфрла вториот. Тестирајте го прекинувачот за ALG или пропуштање на рутерот во двете положби, бидејќи помошник напишан за постар клиент може да ги расипе пакетите што ги праќа сегашниот.

nc -vz 203.0.113.5 1723
sudo tcpdump -ni any proto gre

Граници на идентитетот што личат на транспортни граници

Рутерот не е единствениот сомнителен, а дневникот го разликува од алтернативата. Кога OpenVPN сервер го врзува заедничкото име за една адреса на тунел, двата уреда ја добиваат таа адреса, а без duplicate-cn поновата сесија ја истиснува постарата. Вклучувањето на таа опција ги остава двете поврзани, но ги остава со еден идентитет, еден сертификат и една одлука за отповикување, што е полошо отколку што изгледа. Тогаш вториот уред никогаш не може да се отповика сам, па прекинувачот за удобност тивко отстранува контрола што може да ви затреба подоцна.

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

sudo journalctl -u openvpn-server@server -n 60 --no-pager
cat /run/openvpn/server.status

Усогласете ја поправката со записот во дневникот

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

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

Проверка на две живи сесии

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

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