Miks ühendub sama ruuteri taga ainult üks VPN-klient

Kaks sülearvutit on samas koduvõrgus ja kontori VPN võtab vastu täpselt ühe neist. Teine kas jookseb ajalõppu või ootab, kuni esimene katkestab, ja keegi ei puudutanud kahe katse vahel kliendi seadet. Volitusandmed on samad, mis toimisid minut tagasi, ja see on vihje, et autentimine ei ole tõrke põhjus. Seda mustrit tekitavad kolm mehhanismi ja serveri enda logi ütleb, millisega silmitsi olete.

Lugege lüüsi logi, enne kui klienti puudutate

Serveri kirje mõlema katse kohta vastab esimesele küsimusele ja vastab ühel kolmest viisist. Kui teine katse ei ilmu sellesse logisse kunagi, ei jõudnud pakett kuulajani ja probleemi omab kodune ruuter või teenusepakkuja tee. Kui logi märgib katse ja lükkab selle tagasi, jõudis tunnel kohale, seega on küsimus identiteedis, litsentsis või sessioonilimiidis, mitte milleski kaablil. Kui logi märgib õnnestunud sessiooni, samal ajal kui klient teatab endiselt tõrkest, vaadake tagasiteed või seda, et kahele kliendile antakse sama tunneli aadress.

Telefoni hotspot eraldab need pered odavalt: käivitage teine klient mobiilse andmeside kaudu, samal ajal kui esimene jääb ühendatuks. Edu seal viitab koduvõrgule ja sama tõrge seal viitab lüüsile, jättes ruuteri süütuks. Kumbki tulemus ei ole üksi otsustav, kuid igaüks eemaldab ühe katsega poole otsinguruumist.

Kirjutage tulemus üles enne, kui midagi muudate, sest logi kolm tulemust viivad kolme omavahel mitteseotud paranduseni. Märkus, mis nimetab, millise kolmest te nägite, on väärtuslikum kui kliendi vea ekraanipilt.

Mida ruuter GRE ja NAT-T-ga teeb

PPTP on klassikaline süüdlane: juhtkanal on TCP 1723, andmetee aga GRE, IP-protokoll 47. Paljud tarbijaruuterid tulevad PPTP-abitööriistaga, mis jälgib ühte juhtühendust, nii et teine klient sama NAT-i taga avab oma juhtkanali ja ei saa seejärel üldse andmeteed. TCP-pordi number 47 edasisuunamine ei tee GRE jaoks midagi, sest GRE on protokolli number, mitte port.

L2TP üle IPsec-i käitub konstruktsioonilt teisiti: IKE kasutab UDP 500, NAT-i läbimine viib kaitstud kasuliku koormuse üle UDP 4500-le ja kapseldus on olemas just selleks, et mitu klienti ühe aadressi taga jõuaksid sama lüüsini. See konstruktsioon ei takista lüüsil või vahepealsel seadmel kehtestada aadressipõhist sessioonilimiiti ja diivanilt vaadates näevad mõlemad tõrked ühesugused välja. SoftEtheri oma protokollil on sama klass probleem, kus toimiva läbilasketa ruuter võtab vastu esimese kliendi kohtvõrgust ja viskab teise välja. Katsetage ruuteri ALG- või läbilaskelülitit mõlemas asendis, sest vanemale kliendile kirjutatud abitööriist võib rikkuda pakette, mida praegune saadab.

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

Identiteedilimiidid, mis näevad välja nagu transpordilimiidid

Ruuter ei ole ainus kahtlusalune ja logi eristab seda alternatiivist. Kui OpenVPN-i server seob ühise nime ühe tunneli aadressiga, saavad mõlemad seadmed selle aadressi ja ilma duplicate-cn surub uuem sessioon vanema välja. Selle valiku sisselülitamine jätab mõlemad ühendatuks, kuid jätab nad ühe identiteedi, ühe sertifikaadi ja ühe tühistamisotsusega, mis on hullem, kui näib. Teist seadet ei saa siis enam kunagi eraldi tühistada, nii et mugavuslüliti eemaldab vaikselt juhtimise, mida võite hiljem vajada.

Lugege serveri päevikut ja olekufaili koos, sest üks näitab autentimisotsust ja teine seda, kes parasjagu ühendatud on. Kaks kannet, mis jagavad ühist nime ja üht virtuaalset aadressi, kinnitavad identiteedi kokkupõrke, mitte ruuteri limiidi. Kaubanduslikud lüüsid lisavad omi limiite, näiteks pakett, mis lubab üht samaaegset sessiooni, litsentside arv või reegel, mis lubab üht sessiooni avaliku aadressi kohta, ja ükski ruuteri seade ei muuda neist midagi.

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

Viige parandus vastavusse logikirjega

Logis olev tagasilükkamine nõuab eraldi volitusandmeid seadme kohta, kõrgemat limiiti sellelt, kes teenust haldab, või teist lüüsi lõpp-punkti ühe masina jaoks. Kui ükski teine katse ei jõua kunagi serverini, on püsiv parandus ruuter, mis suunab protokolli edasi ja hoiab rohkem kui üht sessiooni, või transport, mida ruuter hästi käsitleb, näiteks üksik TCP- või UDP-voog. Nende vahel valimine on otsus riistvara eluea, mitte kliendi seadete kohta.

Ärge kopeerige töötava seadme profiili teise masinasse ja pidage asja lõpetatuks. See muudab ühendusprobleemi juurdepääsukontrolli probleemiks, sest kaotatud sülearvutit ei saa enam eristada veel kasutuses olevast koopiast. See peidab ka algse vea, mis naaseb hetkel, kui ilmub kolmas seade.

Kahe elusa sessiooni kontrollimine

Ühendage mõlemad seadmed korraga, käivitage kummaski kavandatud rakendus, seejärel ühendage üks neist uuesti ja korrake. Teine ikoon, mis ilmub korraks, ei tõesta liikluse kohta midagi, ja sessioon, mis kukub kümne minuti pärast, on teine viga teise omanikuga. Võrrelge, mida server lõpuks teatab, sellega, mida kasutajad nägid, sest need kaks aruannet ei klapi sageli.

Kui mõlemad sessioonid jäävad püsima ja kannavad liiklust, peab parandus ja alguses kirjutatud märkusest saab kirje sellest, mis oli valesti. Kui püsib ainult üks, pöörduge tagasi esimese sammu juurde ja kontrollige, milline kolmest logi tulemusest teil nüüd on, sest vastus võib olla muutunud. Ruuteri abitööriistad võivad varjata probleemi, mis ilmub uuesti teises võrgus, samas kui aadressipõhine limiit järgib kasutajat, mitte seadet. Teisest võrgust testimine on odavaim viis teada saada, millise neist te tegelikult parandasite.