Защо зад един и същ рутер се свързва само един 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. Изборът между тях е решение за живота на хардуера, а не за настройките на клиента.

Не копирайте профила на работещо устройство на втората машина и не смятайте въпроса за приключен. Това превръща проблем със свързването в проблем с контрола на достъпа, защото изгубен лаптоп вече не може да се различи от копието, което още се използва. Освен това скрива първоначалната повреда, която се връща в момента, в който се появи трето устройство.

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

Свържете двете устройства едновременно, пуснете желаното приложение на всяко, после свържете отново едно от тях и повторете. Втора икона, която се появи за миг, не доказва нищо за трафика, а сесия, която падне след десет минути, е друга грешка с друг собственик. Сравнете какво съобщава сървърът накрая с това, което потребителите са видели, защото тези два разказа често се разминават.

Ако и двете сесии оцелеят и пренасят трафик, поправката държи и бележката, която написахте в началото, става запис за това какво е било сгрешено. Ако оцелее само една, върнете се към първата стъпка и проверете кой от трите изхода на журнала имате сега, защото отговорът може да се е променил. Помощниците на рутера могат да прикрият проблем, който се появява отново в друга мрежа, докато лимитът за адрес следва потребителя, а не устройството. Тестването от втора мрежа е най-евтиният начин да разберете кое от тези наистина сте поправили.