Чаму за адным роўтарам падключаецца толькі адзін кліент 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. Выбар паміж імі — рашэнне пра тэрмін службы абсталявання, а не пра налады кліента.

Не капіруйце профіль працоўнай прылады на другую машыну і не лічыце справу закрытай. Гэта ператварае праблему злучэння ў праблему кантролю доступу, бо страчаны ноўтбук ужо не адрозніць ад копіі, якая ўсё яшчэ выкарыстоўваецца. Гэта таксама хавае першапачатковую няспраўнасць, якая вяртаецца ў той момант, калі з'яўляецца трэцяя прылада.

Праверка двух жывых сеансаў

Падключыце абедзве прылады адначасова, запусціце патрэбную праграму на кожнай, затым падключыце адну з іх зноў і паўтарыце. Другі значок, які з'яўляецца на імгненне, нічога не даказвае пра трафік, а сеанс, які абрываецца праз дзесяць хвілін, — гэта іншая памылка з іншым уладальнікам. Параўнайце тое, што сервер паведамляе ў рэшце, з тым, што бачылі карыстальнікі, бо гэтыя два сведчанні часта разыходзяцца.

Калі абодва сеансы выжываюць і пераносяць трафік, выпраўленне трымаецца, і нататка, якую вы напісалі спачатку, становіцца запісам пра тое, што было не так. Калі выжывае толькі адзін, вярніцеся да першага кроку і праверце, які з трох вынікаў журнала ў вас цяпер, бо адказ мог змяніцца. Памочнікі роўтара могуць маскіраваць праблему, якая зноў з'яўляецца ў іншай сетцы, а ліміт на адрас ідзе за карыстальнікам, а не за прыладай. Тэставанне з другой сеткі — самы танны спосаб высветліць, якое з гэтага вы сапраўды выправілі.