Kvifor berre éin VPN-klient koplar til bak den same rutaren

To berebare maskiner står på same heimenettverk, og kontorets VPN godtek nøyaktig éin av dei. Den andre går anten ut på tid eller ventar til den første koplar frå, og ingen har rørt ei klientinnstilling mellom dei to forsøka. Påloggingsinformasjonen er den same som verka for eit minutt sidan, og det er sporet som viser at autentisering ikkje er feilen. Tre mekanismar lagar dette mønsteret, og loggen til serveren sjølv seier kva du står overfor.

Les gateway-loggen før du rører ein klient

Registreringa til serveren av begge forsøka svarar på det første spørsmålet, og ho svarar på éin av tre måtar. Viss det andre forsøket aldri dukkar opp i den loggen, nådde pakka aldri lyttaren, og heimerutaren eller vegen til leverandøren eig problemet. Viss loggen registrerer eit forsøk og avviser det, er tunnelen framme, så saka gjeld identitet, lisens eller ei sesjonsgrense og ikkje noko på leidninga. Viss loggen registrerer ein vellukka sesjon medan klienten framleis rapporterer feil, sjå på returvegen eller på at to klientar får same tunneladresse.

Eit hotspot frå telefonen skil desse familiane billeg: køyr den andre klienten over mobildata medan den første blir kopla til. Suksess der peikar på heimenettverket, og den same feilen der peikar på gatewayen, noko som lèt rutaren vere uskuldig. Ingen av resultata er avgjerande åleine, men kvart av dei fjernar halve søkjerommet i eitt forsøk.

Skriv ned resultatet før du endrar noko, fordi dei tre loggresultata fører til tre urelaterte reparasjonar. Eit notat som nemner kva av dei tre du såg, er verd meir enn eit skjermbilete av ein klientfeil.

Kva rutaren gjer med GRE og NAT-T

PPTP er den klassiske syndaren: kontrollkanalen er TCP 1723 medan databanen er GRE, IP-protokoll 47. Mange forbrukarutrar kjem med ein PPTP-hjelpar som følgjer éi kontrolltilkopling, slik at ein annan klient bak same NAT opnar kontrollkanalen sin og deretter ikkje får noka databane i det heile. Å vidasenda ein TCP-port med nummer 47 gjer ingenting for GRE, fordi GRE er eit protokollnummer og ikkje ein port.

L2TP over IPsec oppfører seg annleis av design: IKE brukar UDP 500, NAT-gjennomgang flyttar den verna nyttelasta til UDP 4500, og innkapslinga finst nettopp for at fleire klientar bak éi adresse skal nå same gateway. Det designet hindrar ikkje ein gateway eller ein mellomliggjande boks i å påleggje ei sesjonsgrense per adresse, og frå sofaen ser dei to feila like ut. Den eigne protokollen til SoftEther har same type problem: ein rutar utan fungerande gjennomløp slepp den første klienten inn frå LAN-et og droppar den andre. Test ALG- eller gjennomløpsbrytaren til rutaren i begge stillingar, fordi ein hjelpar skriven for ein eldre klient kan øydeleggje pakkar som ein noverande sender.

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

Identitetsgrenser som ser ut som transportgrenser

Rutaren er ikkje den einaste mistenkte, og loggen skil han frå alternativet. Når ein OpenVPN-server festar eit felles namn til éi tunneladresse, får begge einingane den adressa, og utan duplicate-cn skyt den nyare sesjonen den eldre ut. Å slå på det alternativet lèt begge vere tilkopla, men lèt dei sitje att med éin identitet, eitt sertifikat og éi tilbakekallingsavgjerd, noko som er verre enn det ser ut. Den andre eininga kan då aldri tilbakekallast åleine, så ein bekvemmelegheitsbrytar fjernar stille ein kontroll du kan trengje seinare.

Les journalen til serveren og statusfila saman, fordi den eine viser autentiseringsavgjerda og den andre viser kven som er tilkopla akkurat no. To oppføringar med same felles namn og éi virtuell adresse stadfestar ein identitetskollisjon og ikkje ei rutargrense. Kommersielle gatewayar legg til eigne grenser, som eit abonnement som tillet éin samtidig sesjon, eit lisensnummer eller ei regel som tillet éin sesjon per offentleg adresse, og inga rutarinnstilling endrar noko av det.

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

Match reparasjonen til loggoppføringa

Ei avvising i loggen krev separate påloggingsdata per eining, ei høgare grense frå den som driv tenesta, eller eit andre gateway-endepunkt for éin maskin. Viss ingen andre forsøk nokon gong når serveren, er den varige reparasjonen ein rutar som vidasender protokollen og held meir enn éin sesjon, eller ein transport som rutaren handterer godt, som éin enkelt TCP- eller UDP-straum. Å velje mellom dei er ei avgjerd om levetida til maskinvara, ikkje om klientinnstillingar.

Ikkje kopier profilen til ei fungerande eining over til den andre maskinen og kall det ferdig. Det gjer eit tilkoplingsproblem til eit tilgangskontrollproblem, fordi ein mist bærbar maskin ikkje lenger kan skiljast frå kopien som framleis er i bruk. Det skjuler også den opphavlege feilen, som kjem tilbake i det augneblinken ei tredje eining dukkar opp.

Stadfeste to levande sesjonar

Kopla begge einingane til samtidig, køyr det tiltenkte programmet på kvar, kopla deretter tilbake ein av dei og gjenta. Eit andre ikon som viser seg kort, beviser ingenting om trafikk, og ein sesjon som fell etter ti minutt er ein annan feil med ein annan eigar. Samanlikn det serveren rapporterer til slutt med det brukarane såg, fordi desse to fråsegna ofte er usamde.

Viss begge sesjonane overlever og ber trafikk, held rettinga, og notatet du skreiv i starten blir registreringa av kva som var gale. Viss berre éin overlever, gå tilbake til første steg og kontroller kva av dei tre loggresultata du no har, fordi svaret kan ha endra seg. Rutarhjelparar kan skjule eit problem som dukkar opp igjen på eit anna nettverk, medan ei grense per adresse følgjer brukaren og ikkje eininga. Å teste frå eit anna nettverk er den billegaste måten å finne ut kva av dei du faktisk har retta.