Wêrom't mar ien VPN-klant efter deselde router ferbynt

Twa laptops steane op itselde thúsnetwurk, en de VPN fan kantoar akseptearret krekt ien fan har. De twadde rint yn in tiidsoer of wachtet oant de earste ferbynt, en nimmen hat tusken de twa besykjen in klantynstelling oanrekke. De oanmeldgegevens binne deselde dy't in minút lyn wurken, en dat is it teken dat autentikaasje net de flater is. Trije meganismen meitsje dit patroan, en de log fan 'e tsjinner sels seit hokker jo foar steane.

Lês de log fan 'e poarte foardat jo in klant oanreitsje

De registraasje fan 'e tsjinner fan beide besykjen beantwurdet de earste fraach, en dat docht er op ien fan trije manieren. As it twadde besykjen nea yn dy log ferskynt, hat it pakket de harker nea berikt, en de thúsrouter of it paad fan 'e provider hat it probleem. As de log in besykjen registrearret en it ôfwiist, is de tunnel oankaam, dus giet it om identiteit, lisinsje of in sesjetop en net om eat op 'e tried. As de log in slagge sesje registrearret wylst de klant noch altyd in flater meldt, sjoch dan nei it werompaad of nei twa klanten dy't itselde tunneladres krije.

In hotspot fan in telefoan skiedt dy famyljes goedkeap: rin de twadde klant oer mobile data wylst de earste ferbûn bliuwt. Sukses dêr wiist op it thúsnetwurk, en deselde flater dêr wiist op 'e poarte, wat de router ûnskuldich lit. Gjin fan beide resultaten is op himsels beslissend, mar elk hellet de helte fan 'e sykromte fuort yn ien besykjen.

Skriuw de útkomst op foardat jo eat feroarje, want de trije logútkomsten liede ta trije losse reparaasjes. In notysje dy't neamt hokker fan 'e trije jo seagen is mear wurdich as in skermprint fan in klantflater.

Wat de router mei GRE en NAT-T docht

PPTP is de klassike oertreder: it kontrôlekanaal is TCP 1723 wylst it datapaad GRE is, IP-protokoll 47. In protte konsuminterûters komme mei in PPTP-helper dy't ien kontrôleferbining folget, sadat in twadde klant efter deselde NAT syn kontrôlekanaal iepenet en dan hielendal gjin datapaad krijt. It trochstjoeren fan in TCP-poarte nûmer 47 docht neat foar GRE, want GRE is in protokolnûmer en gjin poarte.

L2TP oer IPsec gedraacht him oars neffens it ûntwerp: IKE brûkt UDP 500, NAT-trochgong ferpleatst de beskerme lading nei UDP 4500, en de ynkapseleing bestiet krekt sadat ferskate klanten efter ien adres deselde poarte berikke kinne. Dat ûntwerp foarkomt net dat in poarte of in tuskenlizzend kastje in sesjetop per adres oplizze, en fan 'e bank ôf lykje de beide flaters itselde. It eigen protokoll fan SoftEther hat deselde klasse probleem: in router sûnder wurkjende trochlitting lit de earste klant fan it LAN ta en smyt de twadde fuort. Test de ALG- of trochlittingsskakel fan 'e router yn beide stannen, want in helper skreaun foar in âldere klant kin pakketten skansearje dy't in hjoeddeistige stjoert.

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

Identiteitstoppen dy't op transporttoppen lykje

De router is net de iennige fertochte, en de log ûnderskiedt him fan it alternatyf. As in OpenVPN-tsjinner in mienskiplike namme oan ien tunneladres fêstset, krije beide apparaten dat adres, en sûnder duplicate-cn skoot de nijere sesje de âldere derút. It oansetten fan dy opsje lit beide ferbûn bliuwe, mar lit se efter mei ien identiteit, ien sertifikaat en ien ynlûkingsbeslút, wat slimmer is as it liket. It twadde apparaat kin dan nea mear allinnich ynlutsen wurde, sadat in gemakskakel stil in kontrôle fuorthellet dy't jo letter nedich wêze kinne.

Lês it deiboek fan 'e tsjinner en syn statusbestân tegearre, want it iene lit it autentikaasjebeslút sjen en it oare wa't op dit stuit ferbûn is. Twa ynfieringen dy't in mienskiplike namme en ien firtuele adres diele, befêstigje in identiteitsbotsing en net in routertop. Kommersjele poarten foegje har eigen toppen ta, lykas in abonnemint dat ien tagelyk sesje tastiet, in lisinsjeoantal of in regel dy't ien sesje per iepenbiere adres tastiet, en gjin routerynstelling feroaret dêr eat oan.

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

Koppelje de reparaasje oan de logynfiering

In ôfwizing yn 'e log freget om aparte oanmeldgegevens per apparaat, in heger top fan wa't de tsjinst rint, of in twadde poartepunt foar ien masine. As gjin twadde besykjen ea de tsjinner berikt, is de bliuwende reparaasje in router dy't it protokoll trochstjoert en mear as ien sesje hâldt, of in transport dat de router goed oan kin, lykas ien TCP- of UDP-stroom. Kieze tusken dy is in beslút oer de libbensdoer fan 'e hardware, net oer klantynstellingen.

Kopiearje it profyl fan in wurkjend apparaat net op 'e twadde masine en neam it dien. Dat makket fan in ferbiningsprobleem in probleem fan tagongskontrôle, want in ferlerne laptop is net mear fan 'e kopy te ûnderskieden dy't noch brûkt wurdt. It ferberget ek de oarspronklike flater, dy't weromkomt op it stuit dat in tredde apparaat ferskynt.

Twa libjende sesjes ferifiearje

Ferbin beide apparaten tagelyk, rin de bedoelde applikaasje op elk, ferbin dan ien fan har op 'e nij en werhelje. In twadde byldkaike dat even ferskynt bewiist neat oer ferkear, en in sesje dy't nei tsien minuten falt is in oare flater mei in oare eigner. Ferlykje wat de tsjinner oan 'e ein meldt mei wat de brûkers seagen, want dy beide ferhalen binne it gauris net iens.

As beide sesjes oerlibje en ferkear drage, hâldt de oplossing en wurdt de notysje dy't jo oan it begjin skreauwen de registraasje fan wat der mis wie. As mar ien oerlibbet, gean werom nei de earste stap en kontrolearje hokker fan 'e trije logútkomsten jo no hawwe, want it antwurd kin feroare wêze. Routerhelpers kinne in probleem ferbergje dat wer op in oar netwurk ferskynt, wylst in top per adres de brûker folget en net it apparaat. Teste fan in twadde netwurk is de bêste manier om út te finen hokker fan dy't jo echt ferholpen hawwe.