Zakaj se za istim usmerjevalnikom poveže samo en odjemalec VPN

Dva prenosnika sta v istem domačem omrežju, in pisarniški VPN sprejme natanko enega od njiju. Drugi bodisi poteče bodisi čaka, da se prvi odklopi, in nihče se med obema poskusoma ni dotaknil nastavitve odjemalca. Poverilnice so iste, ki so delovale pred minuto, in to je namig, da preverjanje pristnosti ni vzrok okvare. Ta vzorec ustvarjajo trije mehanizmi, in dnevnik samega strežnika pove, s katerim se soočate.

Preberite dnevnik prehoda, preden se dotaknete odjemalca

Zapis strežnika o obeh poskusih odgovarja na prvo vprašanje, in odgovarja na enega od treh načinov. Če se drugi poskus v tem dnevniku nikoli ne pojavi, paket ni nikoli prišel do poslušalca, in problem je domačega usmerjevalnika ali poti ponudnika. Če dnevnik poskus zabeleži in ga zavrne, je tunel prispel, torej gre za identiteto, licenco ali omejitev sej, ne za kaj na kablu. Če dnevnik zabeleži uspešno sejo, medtem ko odjemalec še vedno poroča o okvari, poglejte povratno pot ali to, da dva odjemalca dobita isti naslov tunela.

Dostopna točka s telefona ti družini poceni loči: zaženite drugega odjemalca prek mobilnih podatkov, medtem ko prvi ostane povezan. Uspeh tam kaže na domače omrežje, in enaka okvara tam kaže na prehod, kar usmerjevalnik pusti nedolžnega. Noben izid sam zase ni dokončen, a vsak v enem poskusu odstrani polovico iskalnega prostora.

Zapišite izid, preden karkoli spremenite, ker trije izidi dnevnika vodijo v tri nepovezana popravila. Zapis, ki poimenuje, katerega od treh ste videli, je vreden več kot posnetek zaslona z napako odjemalca.

Kaj usmerjevalnik počne z GRE in NAT-T

PPTP je klasičen krivec: krmilni kanal je TCP 1723, medtem ko je podatkovna pot GRE, protokol IP 47. Mnogi potrošniški usmerjevalniki imajo pomočnika za PPTP, ki sledi eni krmilni povezavi, zato drugi odjemalec za istim NAT odpre svoj krmilni kanal in nato ne dobi nobene podatkovne poti. Posredovanje vrat TCP s številko 47 za GRE ne naredi ničesar, ker je GRE številka protokola in ne vrata.

L2TP prek IPsec se že po zasnovi obnaša drugače: IKE uporablja UDP 500, prehod skozi NAT premakne zaščiteni tovor na UDP 4500, in kapsuliranje obstaja prav zato, da lahko več odjemalcev za enim naslovom doseže isti prehod. Ta zasnova ne preprečuje, da bi prehod ali vmesna škatla vsilila omejitev sej na naslov, in s kavča sta obe okvari videti enako. Lastni protokol SoftEther ima isto vrsto težave: usmerjevalnik brez delujočega prepuščanja spusti prvega odjemalca iz lokalnega omrežja in drugega zavrže. Preizkusite stikalo ALG ali prepuščanja na usmerjevalniku v obeh položajih, ker lahko pomočnik, napisan za starejšega odjemalca, poškoduje pakete, ki jih pošilja trenutni.

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

Omejitve identitete, ki so videti kot omejitve prenosa

Usmerjevalnik ni edini osumljenec, in dnevnik ga loči od alternative. Ko strežnik OpenVPN pripne skupno ime na en naslov tunela, obe napravi dobita ta naslov, in brez duplicate-cn novejša seja izrine starejšo. Vklop te možnosti pusti oba povezana, a jima pusti eno identiteto, eno potrdilo in eno odločitev o preklicu, kar je slabše, kot je videti. Druge naprave potem ni več mogoče preklicati samostojno, zato stikalo za udobje tiho odstrani nadzor, ki ga boste morda potrebovali pozneje.

Berite dnevnik strežnika in datoteko stanja skupaj, ker eden kaže odločitev o preverjanju pristnosti, drugi pa, kdo je trenutno povezan. Dva vnosa z istim skupnim imenom in enim navideznim naslovom potrjujeta trk identitet in ne omejitve usmerjevalnika. Komercialni prehodi dodajo svoje omejitve, na primer paket, ki dovoljuje eno sočasno sejo, število licenc ali pravilo, ki dovoljuje eno sejo na javni naslov, in nobena nastavitev usmerjevalnika tega ne spremeni.

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

Ujemite popravilo z vnosom v dnevniku

Zavrnitev v dnevniku zahteva ločene poverilnice za vsako napravo, višjo omejitev od tistega, ki upravlja storitev, ali drugo končno točko prehoda za en stroj. Če noben drugi poskus nikoli ne doseže strežnika, je trajno popravilo usmerjevalnik, ki posreduje protokol in drži več kot eno sejo, ali prenos, ki ga usmerjevalnik dobro obvladuje, na primer en sam tok TCP ali UDP. Izbira med tem je odločitev o življenjski dobi strojne opreme, ne o nastavitvah odjemalca.

Ne kopirajte profila delujoče naprave na drugi stroj in ne razglasite dela za končano. To spremeni težavo s povezavo v težavo z nadzorom dostopa, ker izgubljenega prenosnika ni več mogoče ločiti od kopije, ki je še v uporabi. Skrije tudi prvotno napako, ki se vrne v trenutku, ko se pojavi tretja naprava.

Preverjanje dveh živih sej

Povežite obe napravi hkrati, zaženite predvideno aplikacijo na vsaki, nato eno od njiju znova povežite in ponovite. Druga ikona, ki se za hip pojavi, o prometu ne dokazuje ničesar, in seja, ki pade po desetih minutah, je druga napaka z drugim lastnikom. Primerjajte, kaj strežnik na koncu sporoči, s tem, kar so uporabniki videli, ker se ta dva zapisa pogosto ne ujemata.

Če obe seji preživita in prenašata promet, popravek zdrži, in zapis, ki ste ga napisali na začetku, postane evidenca tega, kaj je bilo narobe. Če preživi samo ena, se vrnite na prvi korak in preverite, katerega od treh izidov dnevnika imate zdaj, ker se odgovor morda je spremenil. Pomočniki usmerjevalnika lahko prikrijejo težavo, ki se spet pojavi v drugem omrežju, medtem ko omejitev na naslov sledi uporabniku in ne napravi. Testiranje iz drugega omrežja je najcenejši način, da ugotovite, kaj od tega ste resnično popravili.