Kial nur unu VPN-kliento konektiĝas malantaŭ la sama enkursigilo

Du tekkomputiloj staras en la sama hejma reto, kaj la oficeja VPN akceptas precize unu el ili. La dua aŭ tempolimas aŭ atendas ĝis la unua malkonektiĝos, kaj neniu tuŝis klientan agordon inter la du provoj. La akreditiloj estas la samaj, kiuj funkciis antaŭ unu minuto, kaj tio estas la indico, ke aŭtentikigo ne estas la fuŝo. Tri mekanismoj produktas ĉi tiun ŝablonon, kaj la propra protokolo de la servilo diras, kiun vi frontas.

Legu la protokolon de la pordego antaŭ ol tuŝi klienton

La rikordo de la servilo pri ambaŭ provoj respondas la unuan demandon, kaj ĝi respondas per unu el tri manieroj. Se la dua provo neniam aperas en tiu protokolo, la paketo neniam atingis la aŭskultanton, kaj la hejma enkursigilo aŭ la vojo de la provizanto posedas la problemon. Se la protokolo registras provon kaj rifuzas ĝin, la tunelo alvenis, do la afero estas identeco, permesilo aŭ limo de seancoj, ne io sur la drato. Se la protokolo registras sukcesan seandon dum la kliento ankoraŭ raportas fuŝon, rigardu la revenan vojon aŭ tion, ke du klientoj ricevas la saman tunelan adreson.

Poŝtelefona alirpunkto disigas tiujn familiojn malkare: lanĉu la duan klienton per poŝtelefonaj datumoj dum la unua restas konektita. Sukceso tie indikas la hejman reton, kaj la sama fuŝo tie indikas la pordegon, kio lasas la enkursigilon senkulpa. Neniu rezulto estas sola decidema, sed ĉiu forigas duonon de la serĉspaco per unu provo.

Skribu la rezulton antaŭ ol ŝanĝi ion ajn, ĉar la tri protokolaj rezultoj kondukas al tri malsamaj riparoj. Noto, kiu nomas, kiun el la tri vi vidis, valoras pli ol ekrankopio de klienta eraro.

Kion la enkursigilo faras kun GRE kaj NAT-T

PPTP estas la klasika kulpulo: la regkanalo estas TCP 1723 dum la datenvojo estas GRE, IP-protokolo 47. Multaj hejmaj enkursigiloj venas kun PPTP-helpilo, kiu spuras unu solan regkonekton, do dua kliento malantaŭ la sama NAT malfermas sian regkanalon kaj poste ricevas tute neniun datenvojon. Plusendi TCP-pordon numeritan 47 faras nenion por GRE, ĉar GRE estas protokola numero, ne pordo.

L2TP super IPsec kondutas alie laŭ la konstruo: IKE uzas UDP 500, NAT-trairo movas la protektitan ŝarĝon al UDP 4500, kaj la enkapsuligo ekzistas ĝuste por ke pluraj klientoj malantaŭ unu adreso povu atingi la saman pordegon. Tiu konstruo ne malhelpas pordegon aŭ interan skatolon starigi limon de seancoj por adreso, kaj de la sofo la du fuŝoj aspektas identaj. La propra protokolo de SoftEther havas la saman klason de problemo: enkursigilo sen funkcianta tralaso akceptas la unuan klienton el la loka reto kaj forĵetas la duan. Testu la ALG- aŭ tralasŝaltilon de la enkursigilo en ambaŭ pozicioj, ĉar helpilo skribita por pli malnova kliento povas difekti paketojn, kiujn sendas nuntempa.

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

Identecaj limoj, kiuj aspektas kiel transportaj limoj

La enkursigilo ne estas la sola suspektato, kaj la protokolo distingas ĝin de la alternativo. Kiam OpenVPN-servilo fiksas komunan nomon al unu tunela adreso, ambaŭ aparatoj ricevas tiun adreson, kaj sen duplicate-cn la pli nova seando elŝovas la pli malnovan. Ŝalti tiun opcion lasas ambaŭ konektitaj sed lasas ilin kun unu identeco, unu atestilo kaj unu revoka decido, kio estas pli malbone ol ĝi aspektas. La dua aparato tiam neniam povas esti revokita sola, do komforta ŝaltilo kviete forigas regadon, kiun vi eble bezonos poste.

Legu la ĵurnalon de la servilo kaj ĝian statan dosieron kune, ĉar unu montras la aŭtentikigan decidon kaj la alia montras, kiu estas nuntempe konektita. Du eroj kun la sama komuna nomo kaj unu virtuala adreso konfirmas identecan kolizion, ne limon de la enkursigilo. Komercaj pordegoj aldonas proprajn limojn, ekzemple planon permesantan unu samtempan seandon, nombron de permesiloj aŭ regulon permesantan unu seandon por publika adreso, kaj neniu agordo de la enkursigilo ŝanĝas ion el tio.

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

Agordigu la riparon al la protokola ero

Rifuzo en la protokolo postulas apartajn akreditilojn por ĉiu aparato, pli altan limon de tiu, kiu funkciigas la servon, aŭ duan pordegan finpunkton por unu maŝino. Se neniu dua provo iam atingas la servilon, la daŭra riparo estas enkursigilo, kiu plusendas la protokolon kaj tenas pli ol unu seandon, aŭ transporto, kiun la enkursigilo bone regas, ekzemple unu TCP- aŭ UDP-fluo. Elekti inter tiuj estas decido pri la vivo de la aparataro, ne pri klientaj agordoj.

Ne kopiu la profilon de funkcianta aparato al la dua maŝino kaj nomu la aferon finita. Tio ŝanĝas konektan problemon al problemo de alirkontrolo, ĉar perdita tekkomputilo ne plu distingiĝas de la kopio ankoraŭ uzata. Ĝi ankaŭ kaŝas la originan fuŝon, kiu revenas en la momento, kiam aperas tria aparato.

Kontroli du vivantajn seancojn

Konektu ambaŭ aparatojn samtempe, lanĉu la celatan aplikaĵon sur ĉiu, poste rekonektu unu el ili kaj ripetu. Dua piktogramo, kiu aperas momente, pruvas nenion pri trafiko, kaj seando, kiu falas post dek minutoj, estas alia fuŝo kun alia posedanto. Komparu, kion la servilo raportas fine, kun tio, kion la uzantoj vidis, ĉar tiuj du raportoj ofte malkongruas.

Se ambaŭ seancoj postvivas kaj portas trafikon, la solvo tenas, kaj la noto, kiun vi skribis komence, fariĝas la rikordo de tio, kio malĝustis. Se postvivas nur unu, revenu al la unua paŝo kaj kontrolu, kiun el la tri protokolaj rezultoj vi nun havas, ĉar la respondo eble ŝanĝiĝis. Helpiloj de la enkursigilo povas kaŝi problemon, kiu reaperas en alia reto, dum limo por adreso sekvas la uzanton, ne la aparaton. Testi el dua reto estas la plej malmultekosta maniero ekscii, kiun el tiuj vi efektive riparis.