Proč se za stejným routerem připojí jen jeden klient VPN

Dva notebooky sedí ve stejné domácí síti a firemní VPN přijme přesně jeden z nich. Druhý buď vyprší, nebo čeká, než se první odpojí, a nikdo mezi oběma pokusy nesáhl na nastavení klienta. Přihlašovací údaje jsou tytéž, které fungovaly před minutou, a to je stopa, že ověřování není příčinou selhání. Tento vzorec vytvářejí tři mechanismy a vlastní log serveru říká, se kterým se potýkáte.

Přečtěte si log brány, než sáhnete na klienta

Záznam serveru o obou pokusech odpovídá na první otázku, a to jedním ze tří způsobů. Pokud se druhý pokus v tom logu vůbec neobjeví, pak paket k naslouchajícímu procesu nikdy nedorazil a problém vlastní domácí router nebo cesta poskytovatele. Pokud log pokus zaznamená a odmítne, tunel dorazil, takže jde o identitu, licenci nebo limit relací, nikoli o něco na drátu. Pokud log zaznamená úspěšnou relaci, zatímco klient stále hlásí selhání, podívejte se na zpáteční cestu nebo na to, zda dva klienti nedostávají stejnou adresu tunelu.

Hotspot z telefonu tyto rodiny levně oddělí: spusťte druhého klienta přes mobilní data, zatímco první zůstává připojený. Úspěch tam ukazuje na domácí síť a stejné selhání tam ukazuje na bránu, takže router zůstává nevinný. Ani jeden výsledek není sám o sobě průkazný, ale každý při jednom pokusu odstraní polovinu prostoru hledání.

Zapište výsledek, než cokoli změníte, protože tři výsledky z logu vedou ke třem nesouvisejícím opravám. Poznámka, která pojmenuje, který ze tří jste viděli, má větší cenu než snímek obrazovky s chybou klienta.

Co router dělá s GRE a NAT-T

PPTP je klasický viník: řídicí kanál je TCP 1723, zatímco datová cesta je GRE, protokol IP 47. Mnoho domácích routerů dodává pomocníka pro PPTP, který sleduje jediné řídicí spojení, takže druhý klient za stejným NAT otevře svůj řídicí kanál a pak nedostane žádnou datovou cestu. Přesměrování TCP portu s číslem 47 pro GRE neudělá nic, protože GRE je číslo protokolu, ne port.

L2TP přes IPsec se chová jinak už z principu: IKE používá UDP 500, průchod přes NAT přesouvá chráněný obsah na UDP 4500 a zapouzdření existuje právě proto, aby se několik klientů za jednou adresou dostalo ke stejné bráně. Tento návrh nebrání bráně ani mezilehlému zařízení zavést limit relací na adresu, a z gauče obě selhání vypadají stejně. Nativní protokol SoftEther má stejnou třídu problému: router bez funkčního průchodu pustí prvního klienta z LAN a druhého zahodí. Vyzkoušejte přepínač ALG nebo průchodu na routeru v obou polohách, protože pomocník psaný pro staršího klienta může poškodit pakety, které posílá současný.

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

Limity identity, které vypadají jako limity přenosu

Router není jediný podezřelý a log ho od alternativy odliší. Když server OpenVPN připne společné jméno k jedné adrese tunelu, obě zařízení dostanou tuto adresu, a bez duplicate-cn novější relace vytlačí starší. Zapnutí této volby nechá obě připojené, ale ponechá jim jednu identitu, jeden certifikát a jedno rozhodnutí o odvolání, což je horší, než to vypadá. Druhé zařízení pak nikdy nelze odvolat samostatně, takže přepínač pohodlí tiše odstraní kontrolu, kterou můžete později potřebovat.

Čtěte log serveru a stavový soubor společně, protože jeden ukazuje rozhodnutí o ověření a druhý, kdo je právě připojený. Dva záznamy se stejným společným jménem a jednou virtuální adresou potvrzují kolizi identity, ne limit routeru. Komerční brány přidávají vlastní limity, například tarif povolující jednu souběžnou relaci, počet licencí nebo pravidlo povolující jednu relaci na veřejnou adresu, a žádné nastavení routeru na tom nic nemění.

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

Slaďte opravu se záznamem v logu

Odmítnutí v logu volá po samostatných přihlašovacích údajích pro každé zařízení, vyšším limitu od toho, kdo službu provozuje, nebo po druhém koncovém bodu brány pro jeden stroj. Pokud žádný druhý pokus na server nikdy nedorazí, trvalou opravou je router, který protokol propouští a udrží víc než jednu relaci, nebo přenos, který router zvládá dobře, například jediný tok TCP nebo UDP. Volba mezi tím je rozhodnutí o životnosti hardwaru, ne o nastavení klienta.

Nekopírujte profil funkčního zařízení do druhého stroje a nepovažujte to za hotové. Tím měníte problém s připojením na problém s řízením přístupu, protože ztracený notebook už nelze rozeznat od kopie, která je stále v použití. Také to skryje původní závadu, která se vrátí ve chvíli, kdy se objeví třetí zařízení.

Ověření dvou živých relací

Připojte obě zařízení současně, spusťte na každém zamýšlenou aplikaci, poté jedno z nich znovu připojte a opakujte. Druhá ikona, která se krátce objeví, o provozu nic nedokazuje, a relace, která spadne po deseti minutách, je jiná chyba s jiným vlastníkem. Porovnejte, co server na konci hlásí, s tím, co viděli uživatelé, protože ty dva záznamy se často rozcházejí.

Pokud obě relace přežijí a přenášejí provoz, oprava drží a poznámka, kterou jste napsali na začátku, se stane záznamem o tom, co bylo špatně. Pokud přežije jen jedna, vraťte se k prvnímu kroku a zkontrolujte, který ze tří výsledků logu teď máte, protože odpověď se mohla změnit. Pomocníci routeru mohou zakrýt problém, který se znovu objeví v jiné síti, zatímco limit na adresu sleduje uživatele, ne zařízení. Testování z druhé sítě je nejlevnější způsob, jak zjistit, který z nich jste skutečně opravili.