Miért csak egy VPN-kliens csatlakozik ugyanazon router mögött

Két laptop van ugyanazon az otthoni hálózaton, és az irodai VPN közülük pontosan egyet fogad el. A második vagy időtúllépésbe fut, vagy megvárja, míg az első bontja a kapcsolatot, és senki nem nyúlt kliensbeállításhoz a két próbálkozás között. A hitelesítő adatok ugyanazok, amelyek egy perccel korábban működtek, és ez az a nyom, hogy nem a hitelesítés a hiba. Három mechanizmus hozza létre ezt a mintát, és a kiszolgáló saját naplója mondja meg, melyikkel áll szemben.

Olvassa el az átjáró naplóját, mielőtt klienshez nyúlna

A kiszolgáló bejegyzése a két próbálkozásról megválaszolja az első kérdést, és háromféleképpen válaszolhat. Ha a második próbálkozás soha nem jelenik meg abban a naplóban, a csomag soha nem érte el a figyelőt, és a probléma az otthoni routeré vagy a szolgáltató útvonaláé. Ha a napló rögzít egy próbálkozást és elutasítja, az alagút megérkezett, tehát identitásról, licencről vagy munkamenet-plafonról van szó, nem a vezetéken lévő valamiről. Ha a napló sikeres munkamenetet rögzít, miközben a kliens még mindig hibát jelez, nézze meg a visszautat, vagy azt, hogy két kliens ugyanazt az alagútcímet kapja.

A telefonos hotspot olcsón szétválasztja ezeket a családokat: futtassa a második klienst mobiladaton, miközben az első kapcsolva marad. Az ottani siker az otthoni hálózatra utal, és az ottani ugyanolyan hiba az átjáróra, ami a routert ártatlanná teszi. Egyik eredmény sem döntő önmagában, de mindegyik egy próbálkozással felezi a keresési teret.

Jegyezze fel az eredményt, mielőtt bármit módosít, mert a napló három kimenetele három független javításhoz vezet. Egy jegyzet, amely megnevezi, melyiket látta a háromból, többet ér, mint egy klienshiba képernyőképe.

Mit tesz a router a GRE-vel és a NAT-T-vel

A PPTP a klasszikus bűnös: a vezérlőcsatorna TCP 1723, míg az adatút GRE, azaz IP-protokoll 47. Sok otthoni router PPTP-segéddel jön, amely egyetlen vezérlőkapcsolatot követ, így az ugyanazon NAT mögötti második kliens megnyitja a vezérlőcsatornáját, majd egyáltalán nem kap adatutat. A 47-es számú TCP-port továbbítása semmit nem tesz a GRE-ért, mert a GRE protokollszám, nem port.

L2TP IPsec fölött tervezésénél fogva másképp viselkedik: az IKE UDP 500-at használ, a NAT-átjárás a védett terhet UDP 4500-ra viszi át, és a beágyazás éppen azért létezik, hogy több kliens egy cím mögül elérhesse ugyanazt az átjárót. Ez a tervezés nem akadályozza meg, hogy egy átjáró vagy egy köztes doboz cím szerinti munkamenet-plafont írjon elő, és a kanapéról a két hiba egyformának látszik. A SoftEther saját protokollja ugyanebbe a problémacsaládba tartozik: a működő átengedés nélküli router beengedi az első klienst a helyi hálózatról, és eldobja a másodikat. Tesztelje a router ALG- vagy átengedéskapcsolóját mindkét állásban, mert egy régebbi klienshez írt segéd tönkreteheti azokat a csomagokat, amelyeket egy mai küld.

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

Identitásplafonok, amelyek szállítási plafonoknak látszanak

Nem csak a router gyanús, és a napló megkülönbözteti a másik lehetőségtől. Amikor egy OpenVPN-kiszolgáló közös nevet rögzít egyetlen alagútcímhez, mindkét eszköz azt a címet kapja, és duplicate-cn nélkül az újabb munkamenet kiszorítja a régebbit. Ennek a beállításnak a bekapcsolása mindkettőt kapcsolatban tartja, de egyetlen identitással, egyetlen tanúsítvánnyal és egyetlen visszavonási döntéssel hagyja őket, ami rosszabb, mint amilyennek látszik. A második eszköz ezután soha nem vonható vissza önállóan, így egy kényelmi kapcsoló csendesen eltávolít egy vezérlést, amelyre később szüksége lehet.

Olvassa a kiszolgáló naplóját és állapotfájlját együtt, mert az egyik a hitelesítési döntést mutatja, a másik pedig azt, hogy éppen ki van kapcsolódva. Két bejegyzés azonos közös névvel és egy virtuális címmel identitásütközést igazol, nem routerplafont. A kereskedelmi átjárók saját plafonokat adnak hozzá, például egy csomagot, amely egyetlen egyidejű munkamenetet enged, licencszámot vagy szabályt, amely nyilvános címenként egy munkamenetet enged, és semmilyen routerbeállítás nem változtat ezeken.

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

Párosítsa a javítást a naplóbejegyzéssel

A naplóban lévő elutasítás eszközönként külön hitelesítő adatokat, magasabb plafont a szolgáltatást működtetőtől, vagy második átjáró-végpontot kíván egy géphez. Ha egyetlen második próbálkozás sem ér el a kiszolgálóhoz, a tartós javítás egy olyan router, amely továbbítja a protokollt és egynél több munkamenetet tart, vagy olyan szállítás, amelyet a router jól kezel, például egyetlen TCP- vagy UDP-folyam. A kettő közötti választás a hardver élettartamáról szóló döntés, nem a kliensbeállításokról.

Ne másolja egy működő eszköz profilját a második gépre, és ne tekintse késznek a dolgot. Ez a kapcsolódási problémát hozzáférés-vezérlési problémává alakítja, mert egy elveszett laptop már nem különböztethető meg a még használatban lévő másolattól. Elrejti az eredeti hibát is, amely abban a pillanatban visszatér, amikor megjelenik egy harmadik eszköz.

Két élő munkamenet ellenőrzése

Csatlakoztassa mindkét eszközt egyszerre, futtassa a szándékolt alkalmazást mindegyiken, majd csatlakoztassa újra az egyiket, és ismételje meg. Egy második ikon, amely rövid ideig megjelenik, semmit nem bizonyít a forgalomról, és a tíz perc után leeső munkamenet más hiba, más felelőssel. Hasonlítsa össze, mit jelent a kiszolgáló a végén azzal, amit a felhasználók láttak, mert ez a két beszámoló gyakran nem egyezik.

Ha mindkét munkamenet túléli és forgalmat visz, a javítás tart, és az elején írt jegyzetből az lesz a feljegyzés, hogy mi volt a hiba. Ha csak az egyik éli túl, térjen vissza az első lépéshez, és ellenőrizze, melyik a három naplókimenetel közül, mert a válasz megváltozhatott. A routersegédek elfedhetnek egy problémát, amely más hálózaton újra megjelenik, míg a cím szerinti plafon a felhasználót követi, nem az eszközt. A második hálózatról végzett teszt a legolcsóbb módja annak, hogy megtudja, melyiket javította valójában.