Hvorfor bare én VPN-klient kobler til bak den samme ruteren

To bærbare maskiner står på samme hjemmenettverk, og kontorets VPN godtar nøyaktig én av dem. Den andre går enten ut på tid eller venter til den første kobler fra, og ingen har rørt en klientinnstilling mellom de to forsøkene. Påloggingsinformasjonen er den samme som virket for et minutt siden, og det er sporet som viser at autentisering ikke er feilen. Tre mekanismer lager dette mønsteret, og serverens egen logg sier hvilken du står overfor.

Les gateway-loggen før du rører en klient

Serverens registrering av begge forsøkene svarer på det første spørsmålet, og den svarer på én av tre måter. Hvis det andre forsøket aldri dukker opp i den loggen, nådde pakken aldri lytteren, og hjemmeruteren eller leverandørens vei eier problemet. Hvis loggen registrerer et forsøk og avviser det, er tunnelen fremme, så saken gjelder identitet, lisens eller en sesjonsgrense og ikke noe på ledningen. Hvis loggen registrerer en vellykket sesjon mens klienten fortsatt rapporterer feil, se på returveien eller på at to klienter får samme tunneladresse.

Et hotspot fra telefonen skiller disse familiene billig: kjør den andre klienten over mobildata mens den første blir koblet til. Suksess der peker på hjemmenettverket, og den samme feilen der peker på gatewayen, noe som lar ruteren være uskyldig. Ingen av resultatene er avgjørende alene, men hvert av dem fjerner halve søkerommet i ett forsøk.

Skriv ned resultatet før du endrer noe, fordi de tre loggresultatene fører til tre urelaterte reparasjoner. Et notat som navngir hvilken av de tre du så, er verdt mer enn et skjermbilde av en klientfeil.

Hva ruteren gjør med GRE og NAT-T

PPTP er den klassiske synderen: kontrollkanalen er TCP 1723 mens databanen er GRE, IP-protokoll 47. Mange forbrukerrutere leveres med en PPTP-hjelper som følger én kontrollforbindelse, slik at en annen klient bak samme NAT åpner sin kontrollkanal og deretter ikke får noen databane i det hele tatt. Å videresende en TCP-port med nummer 47 gjør ingenting for GRE, fordi GRE er et protokollnummer og ikke en port.

L2TP over IPsec oppfører seg annerledes av design: IKE bruker UDP 500, NAT-gjennomgang flytter den beskyttede nyttelasten til UDP 4500, og innkapslingen finnes nettopp for at flere klienter bak én adresse skal nå samme gateway. Det designet hindrer ikke en gateway eller en mellomliggende boks i å pålegge en sesjonsgrense per adresse, og fra sofaen ser de to feilene like ut. SoftEthers egen protokoll har samme type problem: en ruter uten fungerende gjennomløp slipper den første klienten inn fra LAN-et og dropper den andre. Test ruternes ALG- eller gjennomløpsbryter i begge stillinger, fordi en hjelper skrevet for en eldre klient kan ødelegge pakker som en nåværende sender.

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

Identitetsgrenser som ser ut som transportgrenser

Ruteren er ikke den eneste mistenkte, og loggen skiller den fra alternativet. Når en OpenVPN-server fester et felles navn til én tunneladresse, får begge enhetene den adressen, og uten duplicate-cn skyver den nyere sesjonen den eldre ut. Å slå på det alternativet lar begge være tilkoblet, men lar dem sitte igjen med én identitet, ett sertifikat og én tilbakekallingsbeslutning, noe som er verre enn det ser ut. Den andre enheten kan da aldri tilbakekalles alene, så en bekvemmelighetsbryter fjerner stille en kontroll du kan trenge senere.

Les serverens journal og statusfilen sammen, fordi den ene viser autentiseringsbeslutningen og den andre viser hvem som er tilkoblet akkurat nå. To oppføringer med samme felles navn og én virtuell adresse bekrefter en identitetskollisjon og ikke en ruterbegrensning. Kommersielle gatewayer legger til egne grenser, som et abonnement som tillater én samtidig sesjon, et lisensantall eller en regel som tillater én sesjon per offentlig adresse, og ingen ruterinnstilling endrer noe av det.

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

Match reparasjonen til loggoppføringen

En avvisning i loggen krever separate påloggingsdata per enhet, en høyere grense fra den som driver tjenesten, eller et andre gateway-endepunkt for én maskin. Hvis ingen andre forsøk noen gang når serveren, er den varige reparasjonen en ruter som videresender protokollen og holder mer enn én sesjon, eller en transport som ruteren håndterer godt, som en enkelt TCP- eller UDP-strøm. Å velge mellom dem er en beslutning om maskinvarets levetid, ikke om klientinnstillinger.

Ikke kopier profilen til en fungerende enhet over til den andre maskinen og kall det ferdig. Det gjør et tilkoblingsproblem til et tilgangskontrollproblem, fordi en mistet bærbar maskin ikke lenger kan skilles fra kopien som fortsatt er i bruk. Det skjuler også den opprinnelige feilen, som kommer tilbake i det øyeblikket en tredje enhet dukker opp.

Verifisere to levende sesjoner

Koble begge enhetene til samtidig, kjør det tiltenkte programmet på hver, koble deretter tilbake en av dem og gjenta. Et andre ikon som vises kort, beviser ingenting om trafikk, og en sesjon som faller etter ti minutter er en annen feil med en annen eier. Sammenlign det serveren rapporterer til slutt med det brukerne så, fordi disse to beretningene ofte er uenige.

Hvis begge sesjonene overlever og bærer trafikk, holder rettelsen, og notatet du skrev i starten blir registreringen av hva som var galt. Hvis bare én overlever, gå tilbake til første trinn og kontroller hvilket av de tre loggresultatene du nå har, fordi svaret kan ha endret seg. Ruterhjelpere kan skjule et problem som dukker opp igjen på et annet nettverk, mens en grense per adresse følger brukeren og ikke enheten. Å teste fra et annet nettverk er den billigste måten å finne ut hvilket av dem du faktisk har rettet.