Zašto se iza istog usmjerivača povezuje samo jedan VPN klijent

Dva prijenosnika stoje na istoj kućnoj mreži, a uredski VPN prihvaća točno jedan od njih. Drugi ili dočeka istek vremena ili čeka dok se prvi ne odspoji, a nitko 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 poslužitelja kaže s kojim se suočavate.

Pročitajte zapis pristupnika prije nego dirnete klijent

Zapis poslužitelja 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šatelja, a problem drži kućni usmjerivač ili put pružatelja. 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 dobivaju istu adresu tunela.

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

Zapišite ishod prije nego bilo što 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 snimke zaslona s greškom klijenta.

Što usmjerivač 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 usmjerivači 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 pristupnika. Taj dizajn ne sprječava pristupnik 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: usmjerivač bez radnog propuštanja pušta prvog klijenta iz LAN-a i odbacuje drugog. Testirajte ALG ili prekidač propuštanja na usmjerivaču u oba položaja, jer pomoćnik pisan za stariji klijent može pokvariti pakete koje šalje suvremeni.

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

Limiti identiteta koji izgledaju kao transportni

Usmjerivač nije jedini osumnjičeni, a zapis ga razlikuje od alternative. Kada OpenVPN poslužitelj veže zajedničko ime na jednu adresu tunela, oba uređaja dobivaju 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 poslužitelja i datoteku stanja zajedno, jer jedan pokazuje odluku o autentifikaciji, a drugi tko je trenutačno povezan. Dva unosa s istim zajedničkim imenom i jednom virtualnom adresom potvrđuju sudar identiteta, a ne limit usmjerivača. Komercijalni pristupnici dodaju vlastite limite, poput plana koji dopušta jednu istovremenu sesiju, broja licenci ili pravila koje dopušta jednu sesiju po javnoj adresi, i nijedna postavka usmjerivača ne mijenja bilo što od toga.

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

Uskladite popravak s unosom u zapisu

Odbijanje u zapisu traži odvojene podatke za prijavu po uređaju, viši limit od onoga koji vodi uslugu, ili drugu krajnju točku pristupnika za jedan stroj. Ako nijedan drugi pokušaj nikad ne stigne do poslužitelja, trajni popravak je usmjerivač koji prosljeđuje protokol i drži više od jedne sesije, ili transport s kojim usmjerivač dobro izlazi na kraj, poput jednog toka TCP ili UDP. Izbor između toga odluka je o životnom vijeku opreme, a ne o postavkama klijenta.

Ne kopirajte profil uređaja koji radi na drugi stroj i ne proglašavajte posao završenim. Time problem veze pretvarate u problem kontrole pristupa, jer izgubljeni prijenosnik više ne možete razlikovati od kopije koja je još u uporabi. To skriva 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 ponovno povežite jedan od njih i ponovite. Druga ikona koja se nakratko pojavi ne dokazuje ništa o prometu, a sesija koja padne nakon deset minuta drugi je bug s drugim vlasnikom. Usporedite što poslužitelj na kraju javlja s onim što su korisnici vidjeli, jer se ta dva izvještaja često razilaze.

Ako obje sesije prežive i nose promet, popravak drži i bilješka koju ste napisali na početku postaje zapis o tome što 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 usmjerivača 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 što ste od toga zaista popravili.