Hvorfor det bare er én VPN-klient som kobler til bak samme ruter

To maskiner står på samme hjemmenett, og kontor-VPN-en godtar akkurat én av dem. Den andre timer enten ut eller venter til den første kobler fra, og ingen har endret en klientinnstilling mellom de to forsøkene. Påloggingsinformasjonen er identisk med den som fungerte for ett minutt siden, og det er hintet om at autentisering ikke er problemet. Tre mekanismer gir dette mønsteret, og loggen på serveren selv forteller hvilken du møter.

Les loggen på gatewayen før du tar i en klient

Serverens notat om begge forsøkene besvarer det første spørsmålet, og svaret er ett av tre. Dersom det andre forsøket aldri dukker opp i den loggen, kom pakken aldri fram til lytteren, og hjemmeruteren eller leverandørens rute eier problemet. Dersom loggen registrerer et forsøk og avviser det, kom tunnelen fram, altså gjelder saken identitet, lisens eller en grense for sesjoner og ikke noe på kabelen. Dersom loggen registrerer en vellykket sesjon mens klienten fortsatt melder feil, må du se på returveien eller på at to klienter blir tildelt samme tunneladresse.

Et hotspot fra mobilen skiller disse familiene billig: la den andre klienten gå over mobildata mens den første holder seg tilkoblet. Suksess der peker mot hjemmenettet, og samme feil der peker mot gatewayen, slik at ruteren forblir uskyldig. Ingen av resultatene er avgjørende alene, men hvert av dem fjerner halvparten av søkeområdet i ett forsøk.

Noter resultatet før du endrer noe, fordi de tre utfallene i loggen leder til tre atskilte reparasjoner. Et notat som sier hvilket av de tre du så, er mer verdt 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 har en PPTP-hjelper som følger én kontrollforbindelse, slik at en andre klient bak samme NAT åpner kontrollkanalen sin og deretter ikke får noen databane i det hele tatt. Å videresende en TCP-port med nummer 47 gjør ingenting for GRE, siden GRE er et protokollnummer og ikke en port.

L2TP over IPsec oppfører seg annerledes av design: IKE bruker UDP 500, NAT-traversering flytter den beskyttede lasten til UDP 4500, og innkapslingen finnes nettopp for at flere klienter bak én adresse skal nå samme gateway. Designet hindrer ikke en gateway eller en boks imellom i å ilegge en sesjonsgrense per adresse, og fra sofaen ser de to feilene identiske ut. SoftEther sin egen protokoll har samme klasse problem: en ruter uten fungerende gjennomløp slipper den første klienten inn fra LAN-et og slipper den andre. Prøv ALG- eller gjennomløpsbryteren på ruteren i begge stillinger, fordi en hjelper skrevet for en eldre klient kan ødelegge pakker som en moderne 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, mottar begge enhetene den adressen, og uten duplicate-cn presser den nyere sesjonen den eldre ut. Slår du på det alternativet, holder begge seg tilkoblet, men de sitter igjen med én identitet, ett sertifikat og én tilbakekallingsbeslutning, som er verre enn det høres ut. Den andre enheten kan da aldri tilbakekalles alene, så en bekvemmelighetsbryter fjerner stille en kontroll du kan få bruk for senere.

Les journalen og statusfilen på serveren sammen, siden 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 grense i ruteren. Kommersielle gatewayer legger på egne grenser, for eksempel en plan som tillater én samtidig sesjon, et antall lisenser eller en regel som tillater én sesjon per offentlig adresse, og ingen ruterinnstilling endrer noe av dette.

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

Koble reparasjonen til oppføringen i loggen

En avvisning i loggen krever egne påloggingsdata per enhet, en høyere grense fra den som driver tjenesten, eller et andre endepunkt på gatewayen for én maskin. Når 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 bra, for eksempel én enkelt TCP- eller UDP-strøm. Å velge mellom dem er en avgjørelse om maskinvarets levetid, ikke om klientinnstillinger.

Ikke kopier profilen til en enhet som virker over til den andre maskinen og si at jobben er gjort. Det gjør et tilkoblingsproblem til et tilgangskontrollproblem, fordi en mistet maskin ikke lenger kan skilles fra kopien som fortsatt er i bruk. Det skjuler også den opprinnelige feilen, som kommer tilbake i samme øyeblikk som en tredje enhet dukker opp.

Bekrefte to levende sesjoner

Koble begge enhetene til samtidig, start det tiltenkte programmet på hver av dem, koble så en av dem til på nytt og gjenta. Et andre ikon som vises kort, beviser ingenting om trafikken, og en sesjon som faller etter ti minutter er en annen feil med en annen eier. Sammenlign det serveren melder til slutt med det brukerne har sett, fordi disse to beretningene ofte er uenige.

Dersom begge sesjonene overlever og bærer trafikk, holder rettelsen, og notatet du skrev i begynnelsen blir dokumentasjonen av hva som var galt. Dersom bare én overlever, gå tilbake til første steg og sjekk hvilket av de tre loggutfallene du har nå, fordi svaret kan være endret. Ruterhjelpere kan skjule et problem som kommer tilbake på et annet nett, mens en grense per adresse følger brukeren og ikke enheten. Å teste fra et annet nett er den rimeligste måten å finne ut hvilket av disse du faktisk har rettet.