Hoekom net een VPN-kliënt agter dieselfde roeteerder verbind

Twee skootrekenaars sit op dieselfde tuisnetwerk, en die kantoor se VPN aanvaar presies een van hulle. Die tweede wag óf tot tyd uit óf tot die eerste een ontkoppel, en niemand het tussen die twee pogings aan 'n kliëntinstelling geraak nie. Die aanmeldgegewens is dieselfde as dié wat 'n minuut gelede gewerk het, en dit is die leidraad dat stawing nie die fout is nie. Drie meganismes lewer hierdie patroon, en die bediener se eie log sê watter een jy in die gesig staar.

Lees die poortwaglog voordat jy aan 'n kliënt raak

Die bediener se rekord van albei pogings antwoord die eerste vraag, en dit antwoord op een van drie maniere. As die tweede poging nooit in daardie log verskyn nie, het die pakket nooit die luisteraar bereik nie, en die tuisroeteerder of die verskaffer se pad is eienaar van die probleem. As die log 'n poging aanteken en dit verwerp, het die tonnel aangekom, so die kwessie is identiteit, lisensiëring of 'n sessieperk eerder as iets op die draad. As die log 'n suksesvolle sessie aanteken terwyl die kliënt steeds mislukking rapporteer, kyk na die terugpad of na twee kliënte wat dieselfde tonneladres kry.

'n Selfoonhotspot stel daardie families goedkoop uitmekaar: laat die tweede kliënt oor mobiele data loop terwyl die eerste verbind bly. Sukses daar wys op die tuisnetwerk, en dieselfde mislukking daar wys op die poortwag, wat die roeteerder onskuldig laat. Nie een resultaat is op sy eie beslissend nie, maar elkeen skakel die helfte van die soekruimte in een poging uit.

Skryf die uitkoms neer voordat jy enigiets verander, want die drie loguitkomste lei na drie onverwante herstelwerk. 'n Nota wat noem watter een van die drie jy gesien het, is meer werd as 'n skermkopie van 'n kliëntfout.

Wat die roeteerder met GRE en NAT-T doen

PPTP is die klassieke oortreder: die beheerkanaal is TCP 1723 terwyl die datapad GRE is, IP-protokol 47. Baie verbruikersroeteerders lewer 'n PPTP-hulpmiddel wat 'n enkele beheerverbinding volg, so 'n tweede kliënt agter dieselfde NAT maak sy beheerkanaal oop en kry dan glad geen datapad nie. Om 'n TCP-poort genommer 47 deur te stuur doen niks vir GRE nie, want GRE is 'n protokolnommer eerder as 'n poort.

L2TP oor IPsec werk ontwerpmatig anders: IKE gebruik UDP 500, NAT-deurgang skuif die beskermde loonvrag na UDP 4500, en die inkapseling bestaan juis sodat verskeie kliënte agter een adres dieselfde poortwag kan bereik. Daardie ontwerp verhoed nie dat 'n poortwag of 'n tussenliggende middelkassie 'n sessieperk per adres oplê nie, en van die rusbank af lyk die twee mislukkings identies. SoftEther se eie protokol het dieselfde klas probleem, waar 'n roeteerder sonder werkende deurlaat die eerste kliënt van die LAN toelaat en die tweede laat val. Toets die roeteerder se ALG of deurlaatskakelaar in albei standpunte, want 'n hulpmiddel wat vir 'n ouer kliënt geskryf is, kan pakkette korrupteer wat 'n huidige een stuur.

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

Identiteitsperke wat soos vervoerperke lyk

Die roeteerder is nie die enigste verdagte nie, en die log onderskei dit van die alternatief. Wanneer 'n OpenVPN-bediener 'n algemene naam aan een tonneladres koppel, kry albei toestelle daardie adres, en sonder duplicate-cn stoot die nuwer sessie die ouer een uit. Om daardie opsie te aktiveer laat albei verbind bly terwyl hulle met een identiteit, een sertifikaat en een herroepingsbesluit gelaat word, wat erger is as wat dit lyk. Die tweede toestel kan dan nooit op sy eie herroep word nie, so 'n geriefskakelaar verwyder stilweg 'n beheer wat jy later mag nodig kry.

Lees die bediener se joernaal en sy statuslêer saam, want een wys die stawingsbesluit en die ander wys wie tans verbind is. Twee inskrywings wat 'n algemene naam en 'n virtuele adres deel, bevestig 'n identiteitsbotsing eerder as 'n roeteerderperk. Kommersiële poortwagte voeg hul eie perke by, soos 'n plan wat een gelyktydige sessie toelaat, 'n lisensietelling, of 'n reël wat een sessie per openbare adres toelaat, en geen roeteerderinstelling verander enige van daardie nie.

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

Pas die herstel by die loginskrywing

'n Verwerping in die log vra aparte aanmeldgegewens per toestel, 'n hoër perk van wie die diens bedryf, of 'n tweede poortwagpunt vir een masjien. As geen tweede poging ooit die bediener bereik nie, is die blywende herstel 'n roeteerder wat die protokol deurstuur en meer as een sessie hou, of 'n vervoer wat die roeteerder goed hanteer, soos 'n enkele TCP- of UDP-stroom. Om tussen dié te kies is 'n besluit oor hardewareleeftyd, nie oor kliëntinstellings nie.

Moet nie 'n werkende toestel se profiel op die tweede masjien kopieer en dit dan klaar noem nie. Dit verander 'n verbindingsprobleem in 'n toegangsbeheerprobleem, want 'n verlore skootrekenaar kan nie meer van die kopie wat nog in gebruik is onderskei word nie. Dit verberg ook die oorspronklike fout, wat terugkeer die oomblik wanneer 'n derde toestel verskyn.

Twee lewende sessies verifieer

Verbind albei toestelle op dieselfde tyd, laat die beoogde toepassing op elkeen loop, en verbind dan een van hulle weer en herhaal. 'n Tweede ikoon wat kort verskyn, bewys niks oor verkeer nie, en 'n sessie wat ná tien minute val, is 'n ander fout met 'n ander eienaar. Vergelyk wat die bediener aan die einde rapporteer met wat die gebruikers gesien het, want daardie twee weergawes stem dikwels nie ooreen nie.

As albei sessies oorleef en verkeer dra, hou die oplossing, en die nota wat jy aan die begin geskryf het, word die rekord van wat verkeerd was. As net een oorleef, gaan terug na die eerste stap en kyk watter van die drie loguitkomste jy nou het, want die antwoord het dalk verander. Roeteerderhulpmiddels kan 'n probleem verberg wat op 'n ander netwerk weer verskyn, terwyl 'n perk per adres die gebruiker volg eerder as die toestel. Om vanaf 'n tweede netwerk te toets is die goedkoopste manier om uit te vind watter van dié jy werklik reggemaak het.