Az SSH minden percben megszakad a VPN-en? Nem a keepalive a hibás

Az SSH csatlakozik, körülbelül egy percig működik, majd minden alkalommal nagyjából ugyanabban az időközben lefagy. A szokásos magyarázat az idle timeout, ezért az emberek csökkentik az MTU-t és kliens keepalive-okat állítanak be. A WireGuard kapcsolat, amelyen dolgoztam, már mindezen túl volt: kisebb alagút-MTU, client-alive beállítások, beállított alagút-keepalive. A kiesések változatlanul folytatódtak. Az ok egy aszimmetrikus LAN-útvonal volt, és az mintát érdemes felismerni, mert legyőzi az összes időzítőalapú javítást.

A keepalive azt bizonyítja, hogy a gazdagép még hajlandó küldeni. Nem tudja rávenni az állapotot tartó eszközt, hogy lásson egy választ, amely soha nem halad át rajta.

A mítosz: a keepalive-ok megjavítják a csendes kiesést

Az SSH keepalive-ok egyetlen feladatra léteznek: megakadályozni, hogy valami, ami a csendet számolja, eltakarítson egy tétlen munkamenetet. Ezt jól teszik. Nem oldják meg az állapotot tartó eszköz esetét, amely látta az első csomagot az egyik irányban, majd soha nem látta a választ, mert semmi, amit a kliens küld, nem változtatja meg, melyik interfészt használja a válasz.

Az MTU módosítása a másik népszerű javítás, és ugyanaz a hibamódja. Az MTU csökkentése segít a töredezésben és az útvonal-MTU problémákban, és semmit nem tesz egy útvonallal. Ha az időzítők és az MTU már ésszerűek, és a kiesés továbbra is ismétlődő időközben történik, az időköz valahol egy timeoutról beszél, nem a csomagméretről. Írja fel az időközt, és hasonlítsa össze az útvonal minden eszközének állapot-timeoutjaival.

A jel a szabályszerűség együtt egy olyan munkamenettel, amely azon időközön belül használható marad. Az idle timeoutok akkor ütnek, amikor semmi sem történik; ez akkor üt, amikor gépel.

Mit tesz valójában a plusz átjáró

Tegye a laptopot és a VPN-átjárót ugyanarra a LAN-ra, egy külön LAN-tűzfallal alapértelmezett átjáróként. A laptop a VPN felé tartó forgalmat a tűzfalnak küldi, a tűzfal továbbítja az átjárónak, és az átjáró válaszai egyenesen visszamennek a LAN-on át a laptopra. Az a második szakasz soha nem halad át a tűzfalon, ezért az állapottáblája fél kapcsolatot tart.

Az alábbi címek ezt az elrendezést tükrözik:

Laptop:             192.168.50.20
LAN firewall:       192.168.50.1
WireGuard gateway:  192.168.50.10
Remote VPN subnet:  10.77.0.0/24

Az átirányítások és az állapotkezelés ezután egy működő kézfogást olyan kapcsolattá alakítanak, amely később hal meg, nem azonnal. A késleltetés az állapotbejegyzés elöregedése vagy egy szigorúbb ellenőrzés meghibásodása, ezért tűnik az időköz olyan mechanikusnak.

Ebből semmi sem jelenik meg a kliens konfigurációjában, ezért kezdődik a keresése általában a rossz fájlban.

Válasszon egy szándékos útvonalat

A fenti elrendezésnél a távoli alhálózat közvetlen VPN-átjáróra irányítása megszünteti a fél kapcsolatot:

sudo ip route add 10.77.0.0/24 via 192.168.50.10
ip route get 10.77.0.42

Ezek példacímek. A következő ugrásnak elérhetőnek kell lennie a LAN-ján, az előtagnak a szándékolt távoli hálózatnak kell lennie, és a második parancs megmutatja az eredményt, mielőtt támaszkodna rá. Ha az átjáró nincs az alhálózatán, ez az útvonal nem az a javítás, amelyet szeretne.

Ha a tűzfalnak a rendszerek közötti forgalmat kell felügyelnie, a körülötte való átirányítás rossz tervezés. Ehelyett engedje mindkét irányt át a határon, és állítsa be az útvonalakat mindkét oldalon úgy, hogy a visszaút illeszkedjen. A cél egyetlen szándékos útvonal, nem kevesebb állapotellenőrzés.

A Netgate jegyzetek az aszimmetrikus útválasztásról ugyanezt az interfészszintű aszimmetriát és az általa okozott állapotproblémákat írják le, ezért olvassa el őket, mielőtt globálisan lazítja az állapotkezelést. Az ehhez hasonló időzített megszakadások önmagukban nem bizonyítékok. Kezelje a cikket egy hibamód leírásaként, majd bizonyítsa, hogy a saját hálózata megfelel neki, mielőtt megváltoztatja a globális állapotszabályzatot.

Tesztelje mindkét végéről

Olvassa el a laptop útvonalát a cél felé és a cél útvonalát vissza a laptop felé; ez két külön döntés, és valószínűleg csak az egyikük hibás. Egy ping, amely magától az átjárótól sikeres, teljesen elrejtheti a problémát, mert arról a gépről indul, amelynek az útvonala már helyes. Mindkét irányra szüksége van úgy, ahogy a tényleges munkamenet két vége látja.

A javítás után nyissa újra az SSH-t, és tartsa nyitva a munkamenetet jóval azon időközön túl, amely korábban meghiúsult. Ezután tegye állandóvá az útvonalat a jóváhagyott hálózati konfigurációban, mert az egyszeri parancs nem újraindítási terv, és a probléma a következő újraindításnál új rejtéllyel tér vissza.

Mikor rendben van az aszimmetria

Az aszimmetrikus útválasztás sok hálózatban normális, és definíció szerint nem hibás. Akkor válik problémává, amikor az állapotkövetés, a fordítás vagy a szabályzat attól függ, hogy lásson egy útvonalat, amelyet nem lát, és mindegyiknek más a gyógymódja. Ellenőrizze, mire van valójában szüksége a középső eszköznek, mielőtt körülötte újratervez.

A tartós válasz megnevezi a két útvonalat, azt az eszközt, amelynek mindkettőt látnia kell, és azt az útvonalat, amely ezt lehetővé teszi. Ha nem tudja megnevezni az eszközt, még nem találta meg az okot.