Varför bara en VPN-klient ansluter bakom samma router

Två bärbara datorer står på samma hemnätverk, och kontorets VPN accepterar exakt en av dem. Den andra får antingen tidsgräns eller väntar tills den första kopplar från, och ingen har rört en klientinställning mellan de två försöken. Inloggningsuppgifterna är samma som fungerade för en minut sedan, och det är spåret som visar att autentiseringen inte är felet. Tre mekanismer skapar det här mönstret, och serverns egen logg säger vilken du står inför.

Läs gatewayens logg innan du rör en klient

Serverns registrering av båda försöken svarar på den första frågan, och den svarar på ett av tre sätt. Om det andra försöket aldrig dyker upp i den loggen nådde paketet aldrig lyssnaren, och hemmaroutern eller leverantörens väg äger problemet. Om loggen registrerar ett försök och avvisar det är tunneln framme, så frågan gäller identitet, licens eller en sessionsgräns och inte något på ledningen. Om loggen registrerar en lyckad session medan klienten fortfarande rapporterar fel, titta på returvägen eller på att två klienter får samma tunneladress.

En hotspot från telefonen skiljer dessa familjer billigt: kör den andra klienten över mobildata medan den första är kvar ansluten. Framgång där pekar på hemnätverket, och samma fel där pekar på gatewayen, vilket lämnar routern oskyldig. Inget av resultaten är avgörande ensamt, men var och en tar bort halva sökutrymmet i ett försök.

Skriv ner resultatet innan du ändrar något, eftersom loggens tre utfall leder till tre oberoende reparationer. En anteckning som namnger vilket av de tre du såg är värd mer än en skärmbild av ett klientfel.

Vad routern gör med GRE och NAT-T

PPTP är den klassiska boven: kontrollkanalen är TCP 1723 medan datavägen är GRE, IP-protokoll 47. Många konsumentroutrar levereras med en PPTP-hjälpare som följer en enda kontrollanslutning, så en andra klient bakom samma NAT öppnar sin kontrollkanal och får sedan ingen dataväg alls. Att vidarebefordra en TCP-port med nummer 47 gör ingenting för GRE, eftersom GRE är ett protokollnummer och inte en port.

L2TP över IPsec beter sig annorlunda av konstruktion: IKE använder UDP 500, NAT-genomgång flyttar den skyddade nyttolasten till UDP 4500, och inkapslingen finns just för att flera klienter bakom en adress ska nå samma gateway. Den konstruktionen hindrar inte en gateway eller en mellanliggande burk från att införa en sessionsgräns per adress, och från soffan ser de två felen likadana ut. SoftEthers egen protokoll har samma sorts problem: en router utan fungerande genomläpp släpper in den första klienten från LAN:et och tappar den andra. Testa routerns ALG- eller genomläppsbrytare i båda lägena, eftersom en hjälpare skriven för en äldre klient kan fördärva paket som en nuvarande skickar.

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

Identitetsgränser som ser ut som transportgränser

Routern är inte den enda misstänkta, och loggen skiljer den från alternativet. När en OpenVPN-server fäster ett gemensamt namn vid en enda tunneladress får båda enheterna den adressen, och utan duplicate-cn trycker den nyare sessionen ut den äldre. Att slå på det alternativet låter båda vara anslutna men lämnar dem med en identitet, ett certifikat och ett återkallandebeslut, vilket är värre än det ser ut. Den andra enheten kan då aldrig återkallas på egen hand, så en bekvämlighetsbrytare tar tyst bort en kontroll du kan behöva senare.

Läs serverns journal och dess statusfil tillsammans, eftersom den ena visar autentiseringsbeslutet och den andra visar vem som är ansluten just nu. Två poster med samma gemensamma namn och en virtuell adress bekräftar en identitetskollision och inte en routergräns. Kommersiella gateways lägger till egna gränser, som en plan som tillåter en enda samtidig session, ett antal licenser eller en regel som tillåter en session per offentlig adress, och ingen routerinställning ändrar något av det.

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

Matcha reparationen mot loggposten

En avvisning i loggen kräver separata inloggningsuppgifter per enhet, en högre gräns från den som driver tjänsten, eller en andra gateway-slutpunkt för en maskin. Om inget andra försök någonsin når servern är den varaktiga reparationen en router som vidarebefordrar protokollet och håller mer än en session, eller en transport som routern hanterar bra, som en enda TCP- eller UDP-ström. Att välja mellan dem är ett beslut om hårdvarans livslängd, inte om klientinställningar.

Kopiera inte en fungerande enhets profil till den andra maskinen och kalla det klart. Det gör ett anslutningsproblem till ett åtkomstkontrollproblem, eftersom en borttappad bärbar dator inte längre kan skiljas från kopian som fortfarande används. Det döljer också det ursprungliga felet, som återkommer i samma stund som en tredje enhet dyker upp.

Verifiera två levande sessioner

Anslut båda enheterna samtidigt, kör det avsedda programmet på varje, anslut sedan en av dem igen och upprepa. En andra ikon som visas en kort stund bevisar ingenting om trafiken, och en session som faller efter tio minuter är ett annat fel med en annan ägare. Jämför vad servern rapporterar i slutet med vad användarna såg, eftersom dessa två redogörelser ofta är oense.

Om båda sessionerna överlever och bär trafik håller lösningen, och anteckningen du skrev i början blir registreringen av vad som var fel. Om bara en överlever, gå tillbaka till första steget och kontrollera vilket av loggens tre utfall du har nu, eftersom svaret kan ha ändrats. Routerhjälpare kan dölja ett problem som återkommer på ett annat nätverk, medan en gräns per adress följer användaren och inte enheten. Att testa från ett andra nätverk är det billigaste sättet att ta reda på vilket av dem du faktiskt har åtgärdat.