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

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

Pročitajte zapis prolaza prije nego dirnete klijent

Zapis servera o oba pokušaja odgovara na prvo pitanje, i to 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 zabilježi pokušaj i odbije ga, tunel je stigao, pa je riječ o identitetu, licenci ili limitu sesija, a ne o nečemu na žici. Ako zapis zabilježi uspješnu sesiju dok klijent još javlja kvar, pogledajte povratni put ili to da dva klijenta dobijaju istu adresu tunela.

Hotspot s telefona jeftino razdvaja te dvije porodice: pokrenite drugi klijent preko mobilnih podataka dok prvi ostaje povezan. Uspjeh tamo ukazuje na kućnu mrežu, a isti kvar tamo ukazuje 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 prije nego bilo šta promijenite, jer tri ishoda iz zapisa vode u tri nepovezane popravke. Bilješka koja kaže koji ste od tri vidjeli vrijedi više od snimka ekrana s greškom klijenta.

Šta ruter radi s 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 s 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. Prosljeđivanje TCP porta s brojem 47 ne čini ništa za GRE, jer GRE je broj protokola, a ne port.

L2TP preko IPsec-a po dizajnu se ponaša drugačije: IKE koristi UDP 500, NAT prolaz premješ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 sprječava prolaz ili posredni uređaj da nametne limit sesija po adresi, a s 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 certifikat 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 virtualnom adresom potvrđuju sudar identiteta, a ne limit rutera. Komercijalni prolazi dodaju vlastite limite, poput plana koji dozvoljava jednu istovremenu sesiju, broja licenci ili pravila koje dozvoljava jednu sesiju po javnoj adresi, i nijedna postavka rutera ne mijenja 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 prosljeđuje protokol i drži više od jedne sesije, ili transport s kojim ruter dobro izlazi na kraj, poput jednog toka TCP ili UDP. Izbor između toga je odluka o životnom vijeku 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.

Provjera dvije ž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 s drugim vlasnikom. Uporedite šta server na kraju javlja s onim što su korisnici vidjeli, jer se ta dva izvještaja često razilaze.

Ako obje sesije prežive i nose saobraćaj, popravka drži i bilješ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 provjerite koji od tri ishoda zapisa sad imate, jer se odgovor možda promijenio. 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 s druge mreže najjeftiniji je način da saznate šta ste od toga zaista popravili.