Zašto se iza istog rutera povezuje samo jedan VPN klijent

Dva laptopa stoje na istoj kućnoj mreži, a kancelarijski VPN prihvata tačno jedan od njih. Drugi ili dočeka istek vremena ili čeka dok se prvi ne odspoji, a niko nije dirao klijentsku postavku između dva pokušaja. Podaci za prijavu su isti kao oni koji su radili pre minutu, i to je trag da autentifikacija nije uzrok kvara. Tri mehanizma stvaraju ovaj obrazac, a zapis samog servera kaže sa kojim se suočavate.

Pročitajte zapis prolaza pre nego što dirnete klijent

Zapis servera o oba pokušaja odgovara na prvo pitanje, i odgovara na jedan od tri načina. Ako se drugi pokušaj nikad ne pojavi u tom zapisu, paket nikad nije stigao do slušaoca, a problem drži kućni ruter ili put provajdera. Ako zapis zabeleži pokušaj i odbije ga, tunel je stigao, pa je reč o identitetu, licenci ili limitu sesija, a ne o nečemu na žici. Ako zapis zabeleži uspešnu sesiju dok klijent još javlja kvar, pogledajte povratni put ili to da dva klijenta dobijaju istu adresu tunela.

Hotspot sa telefona jeftino razdvaja te dve porodice: pokrenite drugi klijent preko mobilnih podataka dok prvi ostaje povezan. Uspeh tamo upućuje na kućnu mrežu, a isti kvar tamo upućuje na prolaz, što ruter ostavlja nedužnim. Nijedan rezultat nije sam po sebi konačan, ali svaki u jednom pokušaju uklanja polovinu prostora pretrage.

Zapišite ishod pre nego što bilo šta promenite, jer tri ishoda iz zapisa vode u tri nepovezane popravke. Beleška koja kaže koji ste od tri videli vredi više od snimka ekrana sa greškom klijenta.

Šta ruter radi sa GRE i NAT-T

PPTP je klasičan krivac: kontrolni kanal je TCP 1723, a put podataka GRE, IP protokol 47. Mnogi potrošački ruteri dolaze sa PPTP pomoćnikom koji prati jednu kontrolnu vezu, pa drugi klijent iza istog NAT-a otvori svoj kontrolni kanal i zatim ne dobije nikakav put podataka. Propuštanje TCP porta sa brojem 47 ne čini ništa za GRE, jer GRE je broj protokola, a ne port.

L2TP preko IPsec-a se po dizajnu ponaša drugačije: IKE koristi UDP 500, NAT prolaz premešta zaštićeni teret na UDP 4500, a enkapsulacija postoji upravo zato da nekoliko klijenata iza jedne adrese može doći do istog prolaza. Taj dizajn ne sprečava prolaz ili posredni uređaj da nametne limit sesija po adresi, a sa kauča oba kvara izgledaju isto. SoftEther-ov matični protokol ima istu vrstu problema: ruter bez radnog propuštanja pušta prvog klijenta iz LAN-a i odbacuje drugog. Testirajte ALG ili prekidač propuštanja na ruteru u oba položaja, jer pomoćnik pisan za stariji klijent može pokvariti pakete koje šalje savremeni.

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

Limiti identiteta koji izgledaju kao transportni

Ruter nije jedini osumnjičeni, a zapis ga razlikuje od alternative. Kada OpenVPN server veže zajedničko ime na jednu adresu tunela, oba uređaja dobijaju tu adresu, a bez duplicate-cn novija sesija istiskuje stariju. Uključivanje te opcije pušta oba povezana, ali im ostavlja jedan identitet, jedan sertifikat i jednu odluku o opozivu, što je gore nego što izgleda. Drugi uređaj tada nikad ne može biti opozvan samostalno, pa prekidač za udobnost tiho uklanja kontrolu koja vam može zatrebati kasnije.

Čitajte zapis servera i datoteku stanja zajedno, jer jedan pokazuje odluku o autentifikaciji, a drugi ko je trenutno povezan. Dva unosa sa istim zajedničkim imenom i jednom virtuelnom adresom potvrđuju sudar identiteta, a ne limit rutera. Komercijalni prolazi dodaju sopstvene limite, poput plana koji dozvoljava jednu istovremenu sesiju, broja licenci ili pravila koje dozvoljava jednu sesiju po javnoj adresi, i nijedna postavka rutera ne menja bilo šta od toga.

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

Uskladite popravku sa unosom u zapisu

Odbijanje u zapisu traži odvojene podatke za prijavu po uređaju, viši limit od onoga ko vodi uslugu, ili drugu krajnju tačku prolaza za jednu mašinu. Ako nijedan drugi pokušaj nikad ne stigne do servera, trajna popravka je ruter koji propušta protokol i drži više od jedne sesije, ili transport sa kojim ruter dobro izlazi na kraj, poput jednog toka TCP ili UDP. Izbor između toga je odluka o životnom veku opreme, ne o postavkama klijenta.

Ne kopirajte profil uređaja koji radi na drugu mašinu i ne proglašavajte posao završenim. Time problem veze pretvarate u problem kontrole pristupa, jer izgubljeni laptop više ne možete razlikovati od kopije koja je još u upotrebi. To krije i izvorni kvar, koji se vraća onog trenutka kad se pojavi treći uređaj.

Provera dve žive sesije

Povežite oba uređaja istovremeno, pokrenite predviđenu aplikaciju na svakom, zatim ponovo povežite jedan od njih i ponovite. Druga ikona koja se nakratko pojavi ne dokazuje ništa o saobraćaju, a sesija koja padne nakon deset minuta drugi je bug sa drugim vlasnikom. Uporedite šta server na kraju javlja sa onim što su korisnici videli, jer se ta dva izveštaja često razilaze.

Ako obe sesije prežive i nose saobraćaj, popravka drži i beleška koju ste napisali na početku postaje zapis o tome šta nije bilo u redu. Ako preživi samo jedna, vratite se na prvi korak i proverite koji od tri ishoda zapisa sad imate, jer se odgovor možda promenio. Pomoćnici rutera mogu prikriti problem koji se vraća na drugoj mreži, dok limit po adresi prati korisnika, a ne uređaj. Testiranje sa druge mreže najjeftiniji je način da saznate šta ste od toga zaista popravili.