Kodėl už to paties maršrutizatoriaus jungiasi tik vienas VPN klientas

Du nešiojamieji kompiuteriai yra tame pačiame namų tinkle, o biuro VPN priima tiksliai vieną iš jų. Antrasis arba sulaukia laiko limito, arba laukia, kol pirmasis atsijungs, ir niekas tarp abiejų bandymų nelietė kliento nuostatos. Prisijungimo duomenys tie patys, kurie veikė prieš minutę, ir tai yra užuomina, kad autentifikavimas nėra gedimo priežastis. Šį modelį sukuria trys mechanizmai, o paties serverio žurnalas pasako, su kuriuo susiduriate.

Perskaitykite šliuzo žurnalą prieš liesdami klientą

Serverio įrašas apie abu bandymus atsako į pirmą klausimą, ir atsako vienu iš trijų būdų. Jei antrasis bandymas tame žurnale niekada nepasirodo, paketas niekada nepasiekė klausytojo, o problema priklauso namų maršrutizatoriui arba tiekėjo keliui. Jei žurnalas užfiksuoja bandymą ir jį atmeta, tunelis atėjo, vadinasi, klausimas yra tapatybė, licencija arba sesijų riba, o ne kažkas ant laido. Jei žurnalas užfiksuoja sėkmingą sesiją, o klientas vis dar praneša apie gedimą, pažiūrėkite į grįžimo kelią arba į tai, kad dviem klientams duodamas tas pats tunelio adresas.

Telefono prieigos taškas pigiai atskiria tas šeimas: paleiskite antrą klientą mobiliaisiais duomenimis, kol pirmasis lieka prijungtas. Sėkmė ten nurodo namų tinklą, o ta pati nesėkmė ten nurodo šliuzą, todėl maršrutizatorius lieka nekaltas. Nė vienas rezultatas nėra savarankiškai galutinis, bet kiekvienas per vieną bandymą pašalina pusę paieškos erdvės.

Užsirašykite rezultatą prieš ką nors keisdami, nes trys žurnalo baigtys veda prie trijų nesusijusių taisymų. Užrašas, kuris įvardija, kurią iš trijų matėte, vertas daugiau nei kliento klaidos ekrano kopija.

Ką maršrutizatorius daro su GRE ir NAT-T

PPTP yra klasikinis kaltininkas: valdymo kanalas yra TCP 1723, o duomenų kelias yra GRE, IP protokolas 47. Daugelis buitinių maršrutizatorių turi PPTP pagalbininką, kuris seka vieną valdymo ryšį, todėl antras klientas už to paties NAT atidaro savo valdymo kanalą ir tada visai negauna duomenų kelio. TCP prievado numeriu 47 persiuntimas GRE nieko neduoda, nes GRE yra protokolo numeris, o ne prievadas.

L2TP per IPsec elgiasi kitaip iš prigimties: IKE naudoja UDP 500, NAT praėjimas perkelia apsaugotą naudingąją apkrovą į UDP 4500, o inkapsuliavimas egzistuoja būtent tam, kad keli klientai už vieno adreso pasiektų tą patį šliuzą. Ši konstrukcija netrukdo šliuzui ar tarpinei dėžei nustatyti sesijų ribą vienam adresui, o nuo sofos abu gedimai atrodo vienodai. SoftEther savasis protokolas turi tą pačią problemų klasę: maršrutizatorius be veikiančio perleidimo įleidžia pirmą klientą iš vietinio tinklo ir numeta antrą. Išbandykite maršrutizatoriaus ALG arba perleidimo jungiklį abiejose padėtyse, nes pagalbininkas, parašytas senesniam klientui, gali sugadinti paketus, kuriuos siunčia dabartinis.

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

Tapatybės ribos, kurios atrodo kaip transporto ribos

Maršrutizatorius nėra vienintelis įtariamasis, o žurnalas jį skiria nuo alternatyvos. Kai OpenVPN serveris bendrą vardą pririša prie vieno tunelio adreso, abu įrenginiai gauna tą adresą, o be duplicate-cn naujesnė sesija išstumia senesnę. Įjungus tą parinktį abu lieka prijungti, bet lieka su viena tapatybe, vienu sertifikatu ir vienu atšaukimo sprendimu, o tai blogiau, nei atrodo. Tada antrojo įrenginio niekada nebus galima atšaukti atskirai, tad patogumo jungiklis tyliai pašalina kontrolę, kurios gali prireikti vėliau.

Skaitykite serverio žurnalą ir būsenos failą kartu, nes vienas rodo autentifikavimo sprendimą, o kitas – kas šiuo metu prijungtas. Du įrašai su tuo pačiu bendru vardu ir vienu virtualiu adresu patvirtina tapatybių susidūrimą, o ne maršrutizatoriaus ribą. Komerciniai šliuzai prideda savo ribas, pavyzdžiui, planą, leidžiantį vieną vienalaikę sesiją, licencijų skaičių arba taisyklę, leidžiančią vieną sesiją vienam viešajam adresui, ir jokia maršrutizatoriaus nuostata to nepakeis.

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

Suderinkite taisymą su žurnalo įrašu

Atmetimas žurnale reikalauja atskirų prisijungimo duomenų kiekvienam įrenginiui, didesnės ribos iš to, kas valdo paslaugą, arba antrojo šliuzo galinio taško vienai mašinai. Jei joks antrasis bandymas niekada nepasiekia serverio, ilgalaikis taisymas yra maršrutizatorius, kuris persiunčia protokolą ir išlaiko daugiau nei vieną sesiją, arba transportas, kurį maršrutizatorius gerai tvarko, pavyzdžiui, vienas TCP arba UDP srautas. Rinktis tarp to yra sprendimas apie aparatūros tarnavimo laiką, o ne apie kliento nuostatas.

Nekopijuokite veikiančio įrenginio profilio į antrą mašiną ir nelaikykite darbo baigtu. Tai paverčia ryšio problemą prieigos kontrolės problema, nes pamesto nešiojamojo kompiuterio nebepavyks atskirti nuo kopijos, kuri dar naudojama. Tai taip pat paslepia pirminį gedimą, kuris grįžta tą akimirką, kai pasirodo trečias įrenginys.

Dviejų gyvų sesijų patikra

Prijunkite abu įrenginius tuo pačiu metu, paleiskite numatytą programą kiekviename, tada vėl prijunkite vieną jų ir pakartokite. Antra piktograma, kuri trumpam pasirodo, nieko neįrodo apie srautą, o sesija, kuri nutrūksta po dešimties minučių, yra kitas gedimas su kitu šeimininku. Palyginkite, ką serveris praneša pabaigoje, su tuo, ką matė naudotojai, nes šie du pasakojimai dažnai nesutampa.

Jei abi sesijos išlieka ir neša srautą, taisymas laikosi, o pradžioje parašytas užrašas tampa įrašu apie tai, kas buvo negerai. Jei išlieka tik viena, grįžkite prie pirmo žingsnio ir patikrinkite, kurią iš trijų žurnalo baigčių dabar turite, nes atsakymas galėjo pasikeisti. Maršrutizatoriaus pagalbininkai gali paslėpti problemą, kuri vėl pasirodo kitame tinkle, o riba vienam adresui seka naudotoją, o ne įrenginį. Bandymas iš antro tinklo yra pigiausias būdas sužinoti, kurią iš jų tikrai sutvarkėte.