SSH cade pe VPN în fiecare minut? Nu e keepalive

SSH se conectează, funcționează aproximativ un minut, apoi îngheață cam la același interval de fiecare dată. Explicația obișnuită este un timeout de inactivitate, așa că oamenii scad MTU și setează keepalive pe client. Legătura WireGuard la care am lucrat trecuse deja prin toate acestea: un MTU de tunel mai mic, setări client-alive, un keepalive de tunel configurat. Căderile continuau neschimbate. Cauza s-a dovedit a fi o rută LAN asimetrică, iar tiparul merită recunoscut pentru că învinge orice remediu bazat pe temporizatoare.

Un keepalive dovedește că gazda ta este încă dispusă să trimită. Nu poate face un dispozitiv care ține stare să vadă un răspuns care nu trece niciodată prin el.

Mitul: keepalive-urile repară o cădere tăcută

Keepalive-urile SSH există pentru o singură sarcină: să împiedice ceva care numără tăcerea să elimine o sesiune inactivă. Asta o fac bine. Nu rezolvă dispozitivul care ține stare și care a văzut primul pachet într-o direcție, apoi nu a mai văzut niciodată răspunsul, pentru că nimic din ce trimite clientul nu schimbă ce interfață folosește răspunsul.

Schimbarea MTU este cealaltă soluție populară și are același mod de eșec. Reducerea MTU ajută la fragmentare și la problemele MTU de traseu și nu face nimic pentru o rută. Dacă temporizatoarele și MTU sunt deja rezonabile, iar căderea apare în continuare la un interval repetabil, intervalul îți spune despre un timeout undeva, nu despre dimensiunea pachetelor. Notează intervalul și compară-l cu timeout-urile de stare de pe fiecare dispozitiv din traseu.

Indiciul este regularitatea combinată cu o sesiune care rămâne utilizabilă în acel interval. Timeout-urile de inactivitate lovesc când nu se întâmplă nimic; acesta lovește în timp ce tastezi.

Ce face de fapt gateway-ul suplimentar

Pune laptopul și gateway-ul VPN în același LAN, cu un firewall LAN separat ca gateway implicit. Laptopul trimite traficul către VPN firewall-ului, firewall-ul îl transmite gateway-ului, și răspunsurile gateway-ului se întorc direct prin LAN la laptop. Acel al doilea segment nu trece niciodată prin firewall, așa că tabelul său de stare ține jumătate de conexiune.

Adresele de mai jos reflectă această configurație:

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

Redirecționările și tratarea stării transformă apoi un handshake funcțional într-o conexiune care moare mai târziu, nu imediat. Întârzierea este intrarea de stare care îmbătrânește sau o verificare mai strictă care eșuează, de aceea intervalul pare atât de mecanic.

Nimic din toate acestea nu apare în configurația clientului, de aceea căutarea ei începe de obicei în fișierul greșit.

Alege o singură cale deliberată

Pentru configurația de mai sus, rutarea subrețelei la distanță direct către gateway-ul VPN elimină jumătatea de conexiune:

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

Acestea sunt adrese de exemplu. Următorul salt trebuie să fie accesibil în LAN-ul tău, prefixul trebuie să fie rețeaua la distanță dorită, iar a doua comandă îți arată rezultatul înainte să te bazezi pe el. Dacă gateway-ul nu este în subrețeaua ta, această rută nu este remediul pe care îl vrei.

Dacă firewall-ul trebuie să supravegheze traficul dintre acele sisteme, rutarea pe lângă el este o proiectare greșită. În schimb, lasă ambele direcții să traverseze granița și configurează rutele pe fiecare parte astfel încât calea de întoarcere să corespundă. Scopul este o singură cale deliberată, nu mai puțină verificare a stării.

note despre rutarea asimetrică de la Netgate descriu aceeași asimetrie la nivel de interfață și problemele de stare pe care le creează, așa că citește-le înainte de a relaxa global tratarea stării. Deconectările temporizate asemănătoare acestui caz nu sunt dovezi prin ele însele. Tratează articolul ca descrierea unui mod de eșec, apoi demonstrează că propria ta rețea se potrivește cu el înainte de a schimba politica globală de stare.

Testează de la ambele capete

Citește ruta laptopului către destinație și ruta destinației înapoi către laptop; sunt două decizii separate și probabil doar una dintre ele este greșită. Un ping care reușește de la gateway-ul însuși poate ascunde complet problema, pentru că provine de pe mașina a cărei cale este deja corectă. Ai nevoie de ambele direcții așa cum le văd cele două capete ale sesiunii reale.

După remediere, redeschide SSH și ține sesiunea deschisă mult dincolo de intervalul care eșua. Apoi fă ruta permanentă în configurația de rețea aprobată, pentru că o comandă unică nu este un plan de repornire, iar problema va reveni la următoarea repornire cu un mister nou.

Când asimetria este în regulă

Rutarea asimetrică este normală în multe rețele și nu este defectă prin definiție. Devine o problemă când urmărirea stării, traducerea sau politica depind de vederea unei căi pe care nu o văd, iar fiecare dintre acestea are un remediu diferit. Verifică ce cere de fapt dispozitivul din mijloc înainte de a reproiecta în jurul lui.

Răspunsul durabil numește cele două căi, dispozitivul care trebuie să le vadă pe amândouă și ruta care face asta posibil. Dacă nu poți numi dispozitivul, încă nu ai găsit cauza.