Sessielimiet van een gedeeld VPN-account: waarom één apparaat wegvalt

Je voegt een tweede laptop toe aan het account dat al op je telefoon draait, en de tunnel van de telefoon valt binnen een minuut weg. Of het nieuwe apparaat maakt de verbinding nooit af, en de client eindigt op een beleidsbericht in plaats van een time-out. Het netwerk is in beide gevallen in orde; de beslissing is erboven genomen. Een gedeelde login is één identiteit, en de meeste VPN-diensten tellen die identiteit in plaats van het aantal apparaten dat je bezit. Ik werk van het clientscherm naar buiten, omdat het meestal laat zien welke laag je heeft geweigerd.

Lees het bericht van de client voordat je het netwerk aanraakt

Drie fouten lijken op elkaar en zijn het niet. Een time-out betekent dat je pakketten nergens aankwamen. Een TLS- of certificaatfout betekent dat het eindpunt antwoordde, maar de handshake mislukte. Een weigering van authenticatie of beleid betekent dat de gateway je inloggegevens las en ze daarna weigerde. Alleen de derde hoort bij een verhaal over een sessielimiet, dus stel die eerst vast.

OpenVPN-clients bewaren de interessante regels in hun logvenster. Scroll naar de laatste verbindingspoging en niet naar de herhaallus die erop volgt, en zoek naar AUTH_FAILED of een meegestuurde reden. De client meldt vaak een algemene weigering zonder uitleg, dus de volgende stap is de server, niet de instellingen van de client. Apps van providers zijn erger: een bericht over een apparaatlimiet is nuttig, maar een verbinding die na twee seconden inzakt is een beleidsbeslissing, geen verkeerd wachtwoord. Noteer hoe dan ook de naam van het apparaat en het exacte tijdstip; een operator kan dat paar binnen seconden naast een toegangsrecord leggen.

Tel sessies waar de server ze telt

De teller die ertoe doet, woont op de gateway. OpenVPN schrijft een statusbestand wanneer de server met --status wordt gestart, en somt elke verbonden client op met de common name, het echte adres en de verkeerstellers.

cat /var/log/openvpn-status.log
# or query the management socket directly
echo "status 2" | socat - UNIX-CONNECT:/run/openvpn/server.sock

Twee regels met dezelfde common name zijn twee levende sessies onder één certificaat. Standaard houdt OpenVPN ze niet allebei: zonder --duplicate-cn vervangt een tweede verbinding met hetzelfde certificaat de eerste, en het oudere apparaat verliest zijn tunnel. Die vervanging is de signatuur van een identiteitslimiet. Willekeurig pakketverlies koppelt niet beleefd precies één apparaat los op het moment dat een ander verschijnt.

WireGuard heeft geen sessietabel om te bekijken. wg show wg0 toont de peers en hun laatste handshake, en elk ingeschreven apparaat is een peer met een eigen sleutel. Een gedeeld account is daar een configuratiebestand dat naar meerdere machines is gekopieerd, en de limiet komt van wat die configuraties uitgeeft: een providerportaal, een aantal plaatsen of een regel die aan je openbare adres is gebonden. De OpenVPN 2.6-handleiding documenteert de opties aan de serverkant als je je eigen gateway beheert.

Scheid de vier limieten die achter één bericht schuilgaan

De meeste tickets over een gedeeld account zijn een van vier toelatingsbeslissingen. De client kan ze niet onderscheiden, maar het patroon van welk apparaat faalt wel.

Dezelfde identiteit, tweede verbinding. Het nieuwe apparaat werkt en het oude sterft op hetzelfde moment. Dat is een gelijktijdigheidsregel per identiteit die de gateway of het accountsysteem afdwingt. Niets is kapot; de dienst doet wat zijn beleid zegt.

Aantal plaatsen of apparaten op het abonnement. De eerste apparaten blijven verbonden en het volgende wordt geweigerd terwijl de andere blijven draaien. Controleer de apparaatlijst van de provider voordat je een client wijzigt, want een licentielimiet is niet vanaf de clientkant te repareren.

Een limiet die aan je openbare adres is gebonden. Twee laptops achter één thuisrouter falen terwijl dezelfde login vanaf een telefoonhotspot werkt. Verplaats het tweede apparaat naar een ander netwerk om het te testen. Als het daar verbindt, kijk je naar een regel per adres of een NAT-regel, niet naar het aantal van het account.

Een maximum voor de hele server. Iedereen op de gateway faalt op hetzelfde drukke uur, inclusief accounts die gisteren in orde waren. De --max-clients van OpenVPN gedraagt zich zo, en het heeft niets met je ingeschreven apparaten te maken.

Ruim verouderde sessies op voordat je meer plaatsen koopt

Een sessie die slecht eindigde, kan nog een plek vasthouden. RADIUS-boekhouding schrijft een record wanneer een sessie begint en sluit het wanneer de sessie stopt; als een client verdwijnt, komt de stop nooit en houdt de server de sessie tot een tussentijdse update of een time-out verloopt. Op een FreeRADIUS-gateway kun je de open records zien:

SELECT username, acctsessionid, acctstarttime
FROM radacct WHERE acctstoptime IS NULL;

Een open record met een oude starttijd en geen verkeer hoort bij een apparaat dat al weg is. Sluit het via de console van de operator of met een verbrekingsverzoek, voordat je aanneemt dat de limiet echt was. Telefoons verbinden opnieuw wanneer Wi-Fi aan mobiel overdraagt, en een laptop kan één tunnel in het besturingssysteem plus één in een leveranciersapp draaien, wat als twee sessies van één machine telt.

Stop met het delen van één identiteit tussen apparaten die samen draaien

De blijvende oplossing is structureel. Geef elk apparaat zijn eigen certificaat met een unieke common name, of zijn eigen account, en leg vast welke persoon en welke machine het heeft. Op OpenVPN betekent dat één clientcertificaat per apparaat, met --duplicate-cn uit tenzij je overnamegedrag wilt; op WireGuard één sleutelpaar per apparaat, daar gegenereerd en nooit gekopieerd.

Een profiel klonen om een apparaatlimiet te omzeilen breekt intrekking: het intrekken van één kopie snijdt elk apparaat dat die deelt af, en het log kan niet meer zeggen welke machine wat deed. Is de limiet commercieel, dan is de eerlijke oplossing een extra plaats; is het intern beleid, vraag dan om een tweede identiteit met dezelfde toegangsrechten.

Verifieer in een vaste volgorde

Test de reparatie elke keer op dezelfde manier, zodat het resultaat iets betekent.

• Meld je op elk apparaat af en bevestig dat de actieve lijst van de server leeg is; een vermelding die niet opruimt is een verouderde sessie, geen clientfout.
• Verbind de apparaten één voor één en houd de lijst tussen de verbindingen in het oog.
• Moeten er twee samen draaien, bevestig dan dat beide regels verschillende identiteiten dragen en dat beide hun handshake vers houden.
• Herhaal na een overgang van Wi-Fi naar mobiel, omdat opnieuw verbinden een tweede record kan maken.

Valt het oude apparaat nog steeds weg wanneer het nieuwe verbindt, dan dwingt de gateway een regel per identiteit af waarvoor je geen uitzondering hebt gekregen. Breng de operator de apparaatnamen, de tijdstempels en de lijst met actieve sessies; dat maakt van een vage klacht een beleidsvraag die hij kan beantwoorden.