Prečo sa za tým istým routerom pripojí len jeden klient VPN

Dva notebooky sedia v tej istej domácej sieti a firemný VPN prijme presne jeden z nich. Druhý buď vyprší, alebo čaká, kým sa prvý odpojí, a nikto medzi oboma pokusmi nesiahol na nastavenie klienta. Prihlasovacie údaje sú tie isté, ktoré fungovali pred minútou, a to je stopa, že overovanie nie je príčinou zlyhania. Tento vzorec vytvárajú tri mechanizmy a vlastný log servera hovorí, s ktorým sa stretávate.

Prečítajte si log brány, skôr než sa dotknete klienta

Záznam servera o oboch pokusoch odpovedá na prvú otázku, a to jedným z troch spôsobov. Ak sa druhý pokus v tom logu nikdy neobjaví, paket sa k poslucháčovi nikdy nedostal a problém patrí domácemu routeru alebo ceste poskytovateľa. Ak log pokus zaznamená a odmietne ho, tunel dorazil, takže ide o identitu, licenciu alebo limit relácií, nie o niečo na drôte. Ak log zaznamená úspešnú reláciu, zatiaľ čo klient stále hlási zlyhanie, pozrite sa na spätnú cestu alebo na to, či dvaja klienti nedostávajú rovnakú adresu tunela.

Hotspot z telefónu tieto rodiny lacno oddelí: spustite druhého klienta cez mobilné dáta, zatiaľ čo prvý zostáva pripojený. Úspech tam ukazuje na domácu sieť a rovnaké zlyhanie tam ukazuje na bránu, takže router zostáva nevinný. Ani jeden výsledok nie je sám o sebe priekazný, ale každý pri jednom pokuse odstráni polovicu priestoru hľadania.

Zapíšte výsledok, skôr než čokoľvek zmeníte, pretože tri výsledky z logu vedú k trom nesúvisiacim opravám. Poznámka, ktorá pomenuje, ktorý z troch ste videli, má väčšiu cenu než snímka obrazovky s chybou klienta.

Čo router robí s GRE a NAT-T

PPTP je klasický vinník: riadiaci kanál je TCP 1723, zatiaľ čo dátová cesta je GRE, protokol IP 47. Mnohé domáce routery dodávajú pomocníka pre PPTP, ktorý sleduje jediné riadiace spojenie, takže druhý klient za tým istým NAT otvorí svoj riadiaci kanál a potom nedostane žiadnu dátovú cestu. Presmerovanie TCP portu s číslom 47 pre GRE nič neznamená, pretože GRE je číslo protokolu, nie port.

L2TP cez IPsec sa správa inak už z princípu: IKE používa UDP 500, priechod cez NAT presúva chránený obsah na UDP 4500 a zapuzdrenie existuje práve preto, aby sa niekoľko klientov za jednou adresou dostalo k tej istej bráne. Tento návrh nebráni bráne ani sprostredkujúcemu zariadeniu zaviesť limit relácií na adresu, a z gauča obe zlyhania vyzerajú rovnako. Vlastný protokol SoftEther má rovnakú triedu problému: router bez funkčného prepúšťania pustí prvého klienta z lokálnej siete a druhého zahodí. Vyskúšajte prepínač ALG alebo prepúšťania na routeri v oboch polohách, pretože pomocník napísaný pre staršieho klienta môže poškodiť pakety, ktoré posiela súčasný.

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

Limity identity, ktoré vyzerajú ako limity prenosu

Router nie je jediný podozrivý a log ho od alternatívy odlíši. Keď server OpenVPN pripne spoločné meno k jednej adrese tunela, obe zariadenia dostanú túto adresu, a bez duplicate-cn novšia relácia vytlačí staršiu. Zapnutie tejto možnosti nechá obe pripojené, ale ponechá im jednu identitu, jeden certifikát a jedno rozhodnutie o odvolaní, čo je horšie, než to vyzerá. Druhé zariadenie potom nikdy nemožno odvolať samostatne, takže prepínač pohodlia potichu odstráni kontrolu, ktorú môžete neskôr potrebovať.

Čítajte log servera a stavový súbor spolu, pretože jeden ukazuje rozhodnutie o overení a druhý, kto je práve pripojený. Dva záznamy s rovnakým spoločným menom a jednou virtuálnou adresou potvrdzujú kolíziu identity, nie limit routera. Komerčné brány pridávajú vlastné limity, napríklad tarif povoľujúci jednu súbežnú reláciu, počet licencií alebo pravidlo povoľujúce jednu reláciu na verejnú adresu, a žiadne nastavenie routera na tom nič nemení.

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

Zlaďte opravu so záznamom v logu

Odmietnutie v logu si vyžaduje samostatné prihlasovacie údaje pre každé zariadenie, vyšší limit od toho, kto službu prevádzkuje, alebo druhý koncový bod brány pre jeden stroj. Ak sa žiadny druhý pokus nikdy nedostane na server, trvalou opravou je router, ktorý prepúšťa protokol a udrží viac než jednu reláciu, alebo prenos, ktorý router zvláda dobre, napríklad jediný tok TCP alebo UDP. Voľba medzi tým je rozhodnutie o životnosti hardvéru, nie o nastaveniach klienta.

Nekopírujte profil funkčného zariadenia na druhý stroj a nepovažujte to za hotové. Tým meníte problém s pripojením na problém s riadením prístupu, pretože stratený notebook už nemožno odlíšiť od kópie, ktorá sa stále používa. Tiež to skryje pôvodnú závadu, ktorá sa vráti v okamihu, keď sa objaví tretie zariadenie.

Overenie dvoch živých relácií

Pripojte obe zariadenia súčasne, spustite na každom zamýšľanú aplikáciu, potom jedno z nich znova pripojte a zopakujte. Druhá ikona, ktorá sa na chvíľu objaví, o prevádzke nič nedokazuje, a relácia, ktorá spadne po desiatich minútach, je iná chyba s iným vlastníkom. Porovnajte, čo server na konci hlási, s tým, čo videli používatelia, pretože tieto dva záznamy sa často rozchádzajú.

Ak obe relácie prežijú a prenášajú prevádzku, oprava drží a poznámka, ktorú ste napísali na začiatku, sa stane záznamom o tom, čo bolo zle. Ak prežije len jedna, vráťte sa k prvému kroku a skontrolujte, ktorý z troch výsledkov logu teraz máte, pretože odpoveď sa mohla zmeniť. Pomocníci routera dokážu zakryť problém, ktorý sa vráti v inej sieti, zatiaľ čo limit na adresu sleduje používateľa, nie zariadenie. Testovanie z druhej siete je najlacnejší spôsob, ako zistiť, ktorý z nich ste skutočne opravili.