Pse lidhet vetëm një klient VPN pas të njëjtit router

Dy laptopë ndodhen në të njëjtin rrjet shtëpiak, dhe VPN-i i zyrës pranon saktësisht njërin prej tyre. I dyti ose skadon ose pret derisa i pari të shkëputet, dhe askush nuk ka prekur një cilësim klienti midis dy provave. Kredencialet janë të njëjtat që funksiononin një minutë më parë, dhe ky është treguesi që vërtetimi nuk është dështimi. Tre mekanizma e prodhojnë këtë model, dhe regjistri i vetë serverit thotë me cilin përballeni.

Lexoni regjistrin e portës para se të prekni një klient

Regjistrimi i serverit për të dy provat përgjigjet pyetjes së parë, dhe përgjigjet në një nga tre mënyra. Nëse prova e dytë nuk shfaqet kurrë në atë regjistër, paketa nuk arriti kurrë te dëgjuesi, dhe problemi është i routerit të shtëpisë ose i rrugës së ofruesit. Nëse regjistri shënon një provë dhe e refuzon, tuneli ka arritur, pra çështja është identiteti, licenca ose një kufi sesionesh, jo diçka në kabllo. Nëse regjistri shënon një sesion të suksesshëm ndërsa klienti ende raporton dështim, shikoni rrugën e kthimit ose faktin që dy klientëve u jepet e njëjta adresë tuneli.

Një hotspot nga telefoni i ndan lirshëm ato familje: ekzekutoni klientin e dytë përmes të dhënave celulare ndërsa i pari mbetet i lidhur. Suksesi atje tregon rrjetin shtëpiak, dhe i njëjti dështim atje tregon portën, gjë që e lë routerin të pafajshëm. Asnjëri rezultat nuk është vetëm i vendosur, por secili eliminon gjysmën e hapësirës së kërkimit në një provë.

Shkruani rezultatin përpara se të ndryshoni çdo gjë, sepse tre daljet e regjistrit çojnë në tre riparime të palidhura. Një shënim që emërton se cilën nga të tre keni parë vlen më shumë se një pamje ekrani e një gabimi klienti.

Çfarë bën routeri me GRE dhe NAT-T

PPTP është fajtori klasik: kanali i kontrollit është TCP 1723 ndërsa rruga e të dhënave është GRE, protokolli IP 47. Shumë routerë konsumatorë vijnë me një ndihmës PPTP që ndjek një lidhje të vetme kontrolli, kështu që një klient i dytë pas të njëjtit NAT hap kanalin e tij të kontrollit dhe më pas nuk merr fare rrugë të dhënash. Përcjellja e një porte TCP me numrin 47 nuk bën asgjë për GRE, sepse GRE është një numër protokolli dhe jo një port.

L2TP mbi IPsec sillet ndryshe nga vetë konceptimi: IKE përdor UDP 500, kalimi i NAT-it e zhvendos ngarkesën e mbrojtur në UDP 4500, dhe inkapsulimi ekziston pikërisht që disa klientë pas një adrese të arrijnë të njëjtën portë. Ky konceptim nuk pengon një portë ose një kuti të ndërmjetme të vendosë një kufi sesionesh për adresë, dhe nga divani të dyja dështimet duken njësoj. Protokolli i vetë SoftEther ka të njëjtën klasë problemi: një router pa kalim funksional lë brenda klientin e parë nga rrjeti lokal dhe hedh poshtë të dytin. Provoni çelësin ALG ose të kalimit të routerit në të dyja pozicionet, sepse një ndihmës i shkruar për një klient më të vjetër mund të dëmtojë paketat që dërgon një klient i tanishëm.

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

Kufij identiteti që duken si kufij transporti

Routeri nuk është i vetmi i dyshuar, dhe regjistri e dallon atë nga alternativa. Kur një server OpenVPN fikson një emër të përbashkët në një adresë tuneli, të dy pajisjet marrin atë adresë, dhe pa duplicate-cn sesioni më i ri e shtyn jashtë atë më të vjetër. Aktivizimi i asaj opsioni lë të dyja të lidhura por u lë një identitet, një certifikatë dhe një vendim revokimi, gjë që është më keq sesa duket. Pajisja e dytë atëherë nuk mund të revokohet kurrë vetëm, prandaj një çelës komoditeti heq në heshtje një kontroll që mund t'ju duhet më vonë.

Lexoni ditarin e serverit dhe skedarin e statusit së bashku, sepse njëri tregon vendimin e vërtetimit dhe tjetri kush është i lidhur tani. Dy zëra që ndajnë të njëjtin emër të përbashkët dhe një adresë virtuale konfirmojnë një përplasje identiteti dhe jo një kufi routeri. Portat komerciale shtojnë kufijtë e tyre, si një plan që lejon një sesion të vetëm njëkohësisht, një numër licencash ose një rregull që lejon një sesion për adresë publike, dhe asnjë cilësim i routerit nuk ndryshon asgjë nga këto.

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

Përputhni riparimin me zërin e regjistrit

Një refuzim në regjistër kërkon kredenciale të veçanta për çdo pajisje, një kufi më të lartë nga ai që drejton shërbimin, ose një pikë të dytë fundore të portës për një makinë. Nëse asnjë provë e dytë nuk arrin kurrë te serveri, riparimi i qëndrueshëm është një router që përcjell protokollin dhe mban më shumë se një sesion, ose një transport që routeri e trajton mirë, si një rrjedhë e vetme TCP ose UDP. Zgjedhja midis tyre është një vendim për jetëgjatësinë e harduerit, jo për cilësimet e klientit.

Mos kopjoni profilin e një pajisjeje që punon në makinën e dytë dhe mos e konsideroni punën të mbaruar. Kjo e kthen një problem lidhjeje në një problem të kontrollit të aksesit, sepse një laptop i humbur nuk dallohet më nga kopja që vazhdon të përdoret. Ajo fsheh gjithashtu defektin origjinal, i cili kthehet në çastin kur shfaqet një pajisje e tretë.

Verifikimi i dy sesioneve të gjalla

Lidhni të dyja pajisjet në të njëjtën kohë, ekzekutoni aplikacionin e synuar në secilën, më pas rilidhni njërën prej tyre dhe përsëriteni. Një ikonë e dytë që shfaqet për një çast nuk provon asgjë për trafikun, dhe një sesion që bie pas dhjetë minutash është një defekt tjetër me një pronar tjetër. Krahasoni atë që serveri raporton në fund me atë që panë përdoruesit, sepse këto dy tregime shpesh nuk pajtohen.

Nëse të dyja sesionet mbijetojnë dhe transportojnë trafik, rregullimi mbahet, dhe shënimi që shkruat në fillim bëhet regjistri i asaj që ishte gabim. Nëse mbijeton vetëm njëra, kthehuni në hapin e parë dhe kontrolloni cilën nga tre daljet e regjistrit e keni tani, sepse përgjigjja mund të jetë ndryshuar. Ndihmësit e routerit mund të maskojnë një problem që rishfaqet në një rrjet tjetër, ndërsa një kufi për adresë ndjek përdoruesin dhe jo pajisjen. Testimi nga një rrjet i dytë është mënyra më e lirë për të zbuluar cilën prej tyre e keni rregulluar vërtet.