Börja med en jämförelse, inte en slutsats: samma telefon, samma profil, två nät. Om tunneln misslyckas på det ena och fungerar på det andra ligger skillnaden någonstans på vägen och inte i inloggningsuppgifterna. Notera vilken typ av fel du får, eftersom ett avslag före inloggning och en anslutning som inte bär något är två olika problem. Allt nedan förutsätter det testet, gjort med bara nätet ändrat.

En VPN behöver den underliggande anslutningen; den ersätter den inte och kan inte tvinga en operatör att bära det operatören vägrar bära.

Håll telefonen fast och ändra bara nätet

Att ändra nät och server samtidigt lämnar två möjliga orsaker och inget sätt att skilja dem. Jämför samma slutpunkt först på Wi-Fi, sedan på mobildata, och notera det exakta symtomet varje gång. Ett fel före autentiseringen pekar på nåbarhet, ett avslag av inloggningsuppgifterna pekar på kontot, och en ansluten tunnel som inte bär något pekar på routing eller DNS. Bara det första handlar egentligen om nätet.

Ett tydligt avslag vid inloggning hör också till autentiseringskontrollerna, även om det bara visas i ett nät. Vissa operatörer och gästnät fångar upp trafik på sätt som ger vilseledande fel.

Vad åtkomstnätet kan se och vad det kan ta betalt för

Operatören som bär tunneln observerar själva anslutningen: timing, volym och adressen till VPN-slutpunkten. Att kryptera nyttolasten döljer inte dessa egenskaper, och det gäller på en Wi-Fi-länk hemma lika väl som på mobildata. Det en VPN ändrar är vem som kan se vad, och svaret skiljer sig vid varje hopp. Skriv ned det hopp för hopp i stället för att beskriva anslutningen som privat generellt.

Kostnaderna är den andra praktiska skillnaden. Inkapsling, keepalive-signaler och nya försök förbrukar alla byte, och applikationer kan återuppta en överföring efter en överlämning. Det finns också mätt Wi-Fi hemma, så kontrollera enhetens räknare och abonnemanget i stället för att anta att ett av näten är obegränsat.

Portalinloggningar och operatörsbegränsningar

En fångande portal måste uppfyllas innan tunneln kan nå något. Att återansluta VPN släpper inte in en enhet som nätet inte har auktoriserat, och en alltid-på-policy kan göra portalen onåbar. Slutför först inloggningen via det vanliga webbläsarflödet och res sedan tunneln. Om en hanterad policy hindrar den ordningen, följ operatörens eller administratörens dokumenterade process.

Operatörsbegränsningarna är den andra variabeln: vissa vägar bär bara vissa protokoll, vissa översätter adresser aggressivt, och vissa hanterar en adressfamilj annorlunda än en annan. Jämförelsen begränsar felet till vägen utan att identifiera vilken mekanism som är ansvarig.

Överlämning är inte samma sak som återanslutning

När varje nät fungerar för sig, observera en verklig överlämning. Klienten kan upptäcka ändringen och återansluta, eller behålla en session som nu är död. Applikationer som redan används återhämtar sig annorlunda än de som öppnas efter bytet, så en bestående tunnelikon bevisar lite. Testa applikationen du verkligen bryr dig om genom övergången, och notera om den återhämtar sig utan manuellt ingripande.

Om tunneln bara misslyckas efter inaktivitet kan en keepalive-signal hantera ett fall av NAT-tillstånd. Det reparerar inte en svag signal och löser inte varje överlämning. Skilj inaktivitet från rörelse innan du ändrar inställningar.

Notera nätet, steget där felet sker och beteendet genom en överlämning. Dessa tre skiljer ett vägproblem från ett klientproblem.

Relaterade artiklar