SSH val elke minuut op die VPN uit? Die keepalive is nie die skuld nie

SSH maak verbinding, werk omtrent 'n minuut, en vries dan elke keer op ongeveer dieselfde tussenpose. Die algemene verklaring is 'n ledige-tyd verstryking, so mense verlaag die MTU en stel client-keepalives in. 'n WireGuard-skakel waaraan ek gewerk het, het dit alles al deurgegaan: 'n kleiner tonnel-MTU, client-alive-instellings, 'n gekonfigureerde tonnel-keepalive. Die onderbrekings het onveranderd aangehou. Die oorsaak was 'n asimmetriese LAN-roete, en die patroon is die moeite werd om te herken, want dit troef elke tydhouer-gebaseerde oplossing.

'n Keepalive bewys jou gasheer is nog bereid om te stuur. Dit kan nie 'n toestandvolle toestel 'n antwoord laat sien wat nooit daar verbykom nie.

Die mite: keepalives los 'n stil onderbreking op

SSH-keepalives bestaan vir een doel: om te verhoed dat iets wat stilte tel, 'n ledige sessie opruim. Dit doen hulle goed. Hulle spreek nie 'n toestandvolle toestel aan wat die eerste pakket in een rigting gesien het en toe nooit die antwoord gesien het nie, want niks wat die kliënt stuur, verander watter koppelvlak die antwoord gebruik nie.

'n MTU-verandering is die ander gewilde oplossing, en dit het dieselfde foutmodus. Om die MTU te verlaag help fragmentasie en pad-MTU-probleme, en dit doen niks aan 'n roete nie. As jou tydhouers en MTU al redelik is en die onderbreking is steeds op 'n herhaalbare tussenpose, dan vertel die tussenpose jou van 'n verstryking ergens, nie van pakketgrootte nie. Skryf die tussenpose neer en vergelyk dit met die toestand-verstrykings op elke toestel in die pad.

Die aanduiding is reëlmaat saam met 'n sessie wat binne daardie tussenpose bruikbaar bly. Ledige verstrykings tref wanneer niks gebeur nie; hierdie tref terwyl jy tik.

Wat die ekstra deurgang werklik doen

Plaas die skootrekenaar en die VPN-deurgang op dieselfde LAN, met 'n aparte LAN-firewall as die verstekdeurgang. Die skootrekenaar stuur VPN-gerigte verkeer na die firewall, die firewall stuur dit na die deurgang, en die deurgang se antwoorde gaan reguit terug oor die LAN na die skootrekenaar. Daardie tweede been gaan nooit deur die firewall nie, so sy toestandstabel hou 'n halwe verbinding.

Die adresse hieronder weerspieël daardie rangskikking:

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

Herverwysings en toestandhantering verander dan 'n werkende handdruk in 'n verbinding wat later sterf eerder as onmiddellik. Die vertraging is die toestand-inskrywing wat verouder of 'n strenger kontrole wat misluk, en daarom lyk die tussenpose so meganies.

Niks hiervan verskyn in die kliëntkonfigurasie nie, en daarom begin die soektog daarna gewoonlik in die verkeerde lêer.

Kies een doelbewuste pad

Vir die uitleg hierbo verwyder die stuur van die afgeleë subnet regstreeks na die VPN-deurgang die halwe verbinding:

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

Dit is voorbeeldadresse. Die volgende sprong moet op jou LAN bereikbaar wees, die voorvoegsel moet die bedoelde afgeleë netwerk wees, en die tweede opdrag wys jou die resultaat voordat jy daarop staatmaak. As die deurgang nie op jou subnet is nie, is hierdie roete nie die oplossing wat jy wil hê nie.

As die firewall bedoel is om verkeer tussen daardie stelsels te polisieer, is dit verkeerd om dit te omseil. Laat beide rigtings eerder die grens kruis, en konfigureer die roetes aan elke kant sodat die terugpad ooreenstem. Die doel is 'n enkele doelbewuste pad, nie minder toestandkontrole nie.

Netgate se notas oor asimmetriese roetering beskryf dieselfde asimmetrie op koppelvlakvlak en die toestandprobleme wat dit skep, so lees dit voordat jy toestandhantering wêreldwyd verslap. Tydgebonde ontkoppelings soos hierdie geval is op hul eie nie bewyse nie. Behandel die artikel as 'n beskrywing van een foutmodus, en bewys dan dat jou eie netwerk daarby pas voordat jy globale toestandbeleid verander.

Toets dit van albei kante

Lees die skootrekenaar se roete na die bestemming en die bestemming se roete terug na die skootrekenaar; dit is twee aparte besluite en waarskynlik net een daarvan is verkeerd. 'n Ping wat van die deurgang self slaag, kan die probleem heeltemal verberg, want dit ontstaan op die masjien wie se pad al korrek is. Jy het albei rigtings nodig soos gesien deur die twee ente van die werklike sessie.

Maak SSH ná die oplossing oop en hou die sessie lank verby die tussenpose wat vroeër gefaal het. Maak die roete dan volhoubaar in die goedgekeurde netwerkkonfigurasie, want 'n eenmalige opdrag is nie 'n herbeginplan nie en die probleem sal by die volgende herbegin terugkeer met 'n nuwe raaisel.

Wanneer asimmetrie reg is

Asimmetriese roetering is normaal in baie netwerke en is nie per definisie stukkend nie. Dit word 'n probleem wanneer toestandopvolging, vertaling of beleid daarvan afhang om 'n pad te sien wat hy nie sien nie, en elkeen daarvan het 'n ander oplossing. Kyk wat die middelste toestel werklik vereis voordat jy rondom dit herontwerp.

Die blywende antwoord noem die twee paaie, die toestel wat albei moet sien, en die roete wat dit moontlik maak. As jy nie die toestel kan noem nie, het jy nog nie die oorsaak gevind nie.