Hvorfor kun én VPN-klient opretter forbindelse bag den samme router

To bærbare står på det samme hjemmenetværk, og kontorets VPN accepterer præcis én af dem. Den anden løber enten tør for tid eller venter, indtil den første afbryder, og ingen har rørt en klientindstilling mellem de to forsøg. Legitimationsoplysningerne er de samme, som virkede for et minut siden, og det er sporet, der viser, at godkendelse ikke er fejlen. Tre mekanismer frembringer dette mønster, og serverens egen log siger, hvilken du står over for.

Læs gatewayens log, før du rører en klient

Serverens registrering af begge forsøg besvarer det første spørgsmål, og den svarer på en af tre måder. Hvis det andet forsøg aldrig optræder i den log, nåede pakken aldrig lytteren, og hjemmerouteren eller udbyderens vej ejer problemet. Hvis loggen registrerer et forsøg og afviser det, er tunnelen nået frem, så spørgsmålet er identitet, licens eller et sessionsloft og ikke noget på ledningen. Hvis loggen registrerer en vellykket session, mens klienten stadig rapporterer fejl, så se på returvejen eller på, at to klienter får den samme tunneladresse.

Et hotspot fra telefonen skiller de familier billigt: kør den anden klient over mobildata, mens den første bliver forbundet. Succes der peger på hjemmenetværket, og den samme fejl der peger på gatewayen, hvilket lader routeren være uskyldig. Ingen af resultaterne er afgørende alene, men hvert af dem fjerner halvdelen af søgerummet i ét forsøg.

Skriv resultatet ned, før du ændrer noget, fordi de tre logresultater fører til tre ubeslægtede reparationer. En note, der navngiver, hvilken af de tre du så, er mere værd end et skærmbillede af en klientfejl.

Hvad routeren gør med GRE og NAT-T

PPTP er den klassiske synder: kontrolkanalen er TCP 1723, mens datastien er GRE, IP-protokol 47. Mange forbrugerroutere leveres med en PPTP-hjælper, der følger én kontrolforbindelse, så en anden klient bag den samme NAT åbner sin kontrolkanal og får derefter slet ingen datasti. At videresende en TCP-port med nummer 47 gør intet for GRE, fordi GRE er et protokolnummer og ikke en port.

L2TP over IPsec opfører sig anderledes af design: IKE bruger UDP 500, NAT-gennemløb flytter den beskyttede nyttelast til UDP 4500, og indkapslingen findes netop, for at flere klienter bag én adresse kan nå den samme gateway. Det design forhindrer ikke en gateway eller en mellemliggende boks i at pålægge et sessionsloft pr. adresse, og fra sofaen ser de to fejl ens ud. SoftEthers egen protokol har samme slags problem, hvor en router uden fungerende gennemløb lukker den første klient fra LAN'et ind og dropper den anden. Test routerens ALG- eller gennemløbskontakt i begge stillinger, fordi en hjælper skrevet til en ældre klient kan ødelægge pakker, som en nuværende sender.

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

Identitetslofter, der ligner transportlofter

Routeren er ikke den eneste mistænkte, og loggen skelner den fra alternativet. Når en OpenVPN-server fastlåser et fælles navn til én tunneladresse, får begge enheder den adresse, og uden duplicate-cn skubber den nyere session den ældre ud. At slå den valgmulighed til lader begge være forbundet, men efterlader dem med én identitet, ét certifikat og én tilbagekaldelsesbeslutning, hvilket er værre, end det ser ud. Den anden enhed kan så aldrig tilbagekaldes alene, så en bekvemmelighedskontakt fjerner stille en kontrol, du kan få brug for senere.

Læs serverens journal og dens statusfil sammen, fordi den ene viser godkendelsesbeslutningen, og den anden viser, hvem der er forbundet lige nu. To poster med samme fælles navn og en virtuel adresse bekræfter et identitetssammenstød og ikke et routerloft. Kommercielle gateways lægger deres egne lofter oveni, såsom et abonnement, der tillader én samtidig session, et licensantal eller en regel, der tillader én session pr. offentlig adresse, og ingen routerindstilling ændrer noget af det.

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

Match reparationen til logposten

En afvisning i loggen kræver separate legitimationsoplysninger pr. enhed, et højere loft fra den, der driver tjenesten, eller et andet gateway-endepunkt til én maskine. Hvis ingen andet forsøg nogensinde når serveren, er den holdbare reparation en router, der videresender protokollen og holder mere end én session, eller en transport, som routeren håndterer godt, såsom en enkelt TCP- eller UDP-strøm. At vælge mellem dem er en beslutning om hardwarens levetid, ikke om klientindstillinger.

Kopier ikke en fungerende enheds profil over på den anden maskine og kald det færdigt. Det gør et forbindelsesproblem til et adgangskontrolproblem, fordi en mistet bærbar ikke længere kan skelnes fra kopien, der stadig er i brug. Det skjuler også den oprindelige fejl, som vender tilbage i det øjeblik, en tredje enhed dukker op.

Verificering af to levende sessioner

Forbind begge enheder samtidig, kør det tilsigtede program på hver, og genopret derefter forbindelsen til en af dem og gentag. Et andet ikon, der vises kort, beviser intet om trafik, og en session, der falder efter ti minutter, er en anden fejl med en anden ejer. Sammenlign, hvad serveren rapporterer til sidst, med hvad brugerne så, fordi de to beretninger ofte er uenige.

Hvis begge sessioner overlever og bærer trafik, holder rettelsen, og den note, du skrev i starten, bliver registreringen af, hvad der var galt. Hvis kun én overlever, gå tilbage til første trin og kontrollér, hvilket af de tre logresultater du nu har, fordi svaret kan være ændret. Routerhjælpere kan maskere et problem, der dukker op igen på et andet netværk, mens et loft pr. adresse følger brugeren og ikke enheden. Test fra et andet netværk er den billigste måde at finde ud af, hvilket af dem du faktisk har rettet.