Hvilken innlogging feilet: eduroam-tilgangen eller VPN-en?
Å bli med i eduroam er onboarding på et tilgangsnett; å bli med i en VPN er et eget forhold. Avgjør hvilken innlogging som faktisk feilet før noen endrer en port.
Bak setningen «VPN-en virker ikke på eduroam» ligger to innlogginger, og ulike team eier dem. Å bli med i eduroam bringer enheten inn på et tilgangsnett; å bli med i en VPN bygger et andre forhold oppå den forbindelsen. Begge kan drives av samme institusjon, men påloggingsdetaljene, profilen og trinnet der det bryter sammen holdes atskilt. Finn ut hvilken av de to som faktisk feilet, før noen redigerer et portnummer. Alt nedenfor er organisert rundt denne ene forgreningen.
Én campus der OpenVPN svarte på UDP 1194 er nyttig historie, ikke en oppskrift for den neste.
Bevis tilgangssiden først
Slå av tunnelen og last en vanlig HTTP-side eller en captive portal. Hvis den åpnes, gjør tilgangsnettet jobben sin, og VPN-spørsmålet er virkelig åpent. Hvis ingenting lastes, sitter feilen i assosiasjonen, kontoen eller onboardingprofilen. Ingen endring i VPN-en vil berøre noen av de tre.
Veiledningen for eduroam-tilkobling gjør hjeminstitusjonen til kilden for brukerens identitet. Når en konfigurasjonsassistent bygger en profil, gir valget av den besøkte institusjonen i stedet for hjeminstitusjonen et oppsett som ikke kan autentisere. Bruk det hjeminstitusjonen publiserer, ikke en sertifikatpakke fra et annet sted.
Å slå av en sertifikat- eller autentiseringssjekk for å komme forbi en innlogging gjør en reparerbar feilkonfigurasjon permanent. Hvis den installerte profilen kommer fra en ikke-godkjent kilde, erstatt den før du undersøker noe annet.
Hvem eier hvilken feil
Når tilgangen virker, har hvert gjenværende spørsmål nøyaktig én eier. Her er hele inndelingen:
| Owner | Questions that belong to them |
|---|---|
| VPN operator | Server name, protocol, transport, port, client compatibility, VPN authentication |
| Visited network operator | Which traffic the local arrangement permits, and any observed path problem |
| Device or client administrator | Local policy, client build, server-identity errors |
Transportraden er der de fleste selvgjorte forsøk feiler. Det serveren lytter på er fastsatt i konfigurasjonen, og redigering av klientprofilen kan ikke endre det, så be operatøren om gjeldende profil i stedet for å bytte mellom TCP og UDP. Bytte endrer bare måten klienten feiler på.
På den besøkte siden sier en vellykket eduroam-autentisering ingenting om hvorvidt den veien bærer en gitt VPN-transport, og en timeout alene er ikke bevis på blokkering. Begge påstandene fremsettes daglig, og hver av dem trenger en observasjon bak seg.
På enhetssiden er en administrert sikkerhetsregel, en inkompatibel klientversjon og en serveridentitetsfeil tre forskjellige feil. Å samle dem i én sak forsinker alle tre.
Velg beviset før teorien
Der profilen er din å teste og operatøren har godkjent den, slår én sammenligning en diskusjon: kobler samme profil til fra et annet betrodd nett? Et «ja» peker på den besøkte veien, et «nei» på profilen, serveren eller klienten. Kjør den testen innenfor reglene som gjelder for kontoen, og aldri ved å installere en klient ingen har godkjent.
Hvis operatøren publiserer en godkjent alternativ profil, bruk den. Å finne opp en lytter på en ny port eller lempe på nettets regler gir et resultat ingen kan forsvare senere, og det skjuler den opprinnelige feilen.
Skriv resultatet i den formen de tre eierne kan handle på, ikke den som er raskest å skrive. En naken timeout sier ingenting nyttig til VPN-operatøren, og en autentiseringsfeil sier den besøkte nettoperatøren like lite.
Én logglinje avgjør det ofte. TLS Error: TLS key negotiation failed to occur within 60 seconds peker på veien eller porten, mens AUTH_FAILED betyr at tunnelen ble nådd og påloggingsdetaljene ble avvist.
Skriv overleveringen i fem linjer
En kort overlevering bærer fem ting: det besøkte stedet, tidspunktet for forsøket, den godkjente klientversjonen, serveren og transporten profilen pekte på, og den tidligste informative feilen. Legg til om vanlig tilgang virket, og om en godkjent sammenligning på tvers av nett ble gjort, hvis du har de to. Sladd passord, tokens og private nøkler før dette forlater skrivebordet ditt.
Hvis VPN-en autentiserer og en privat applikasjon deretter feiler, send det senere resultatet videre for seg. Begge de tidligere spørsmålene er besvart innen da, og å brette dem inn i en ny «fortsatt ødelagt»-rapport sender alle tilbake til start.
Fem linjer, tre eiere, én forgrening: det er hele avgjørelsen, og den tas vanligvis før noen berører et portnummer.