SSH dettur á VPN á mínútu fresti? Það er ekki keepalive-ið
Seta sem deyr á endurteknu bili tapar yfirleitt stöðu eldveggjar, ekki keepalive. Fylgdu báðum áttum áður en þú snertir MTU eða tímamæla.
SSH tengist, virkar um mínútu og frýs svo á um það bil sama bili í hvert sinn. Algeng skýring er aðgerðarleysi timeout, svo fólk lækkar MTU og stillir keepalive á biðlaranum. WireGuard-tengingin sem ég vann við hafði þegar farið í gegnum allt þetta: minna MTU göngunnar, client-alive stillingar, stillt keepalive göngunnar. Rofin héldu áfram óbreytt. Orsökin reyndist ósamhverf LAN-leið, og mynstrið er þess virði að þekkja því það sigrar hverja tímamæla-lausn.
Keepalive sannar að hýsillinn þinn sé enn tilbúinn að senda. Það getur ekki fengið tæki sem heldur stöðu til að sjá svar sem fer aldrei í gegnum það.
Goðsögnin: keepalive laga hljóðlaust rof
SSH keepalive eru til fyrir eitt verk: að koma í veg fyrir að eitthvað sem telur þögn hreinsi aðgerðarlausa setu. Það gera þau vel. Þau leysa ekki tæki sem heldur stöðu sem sá fyrstu pakkann í aðra átt og sá síðan aldrei svarið, því ekkert sem biðlarinn sendir breytir því hvaða tengi svarið notar.
MTU-breyting er hin vinsæla lausn, og hún hefur sama bilunarmáta. Að lækka MTU hjálpar við sundrun og MTU-vandamál á leið, og gerir ekkert fyrir leið. Ef tímamælarnir þínir og MTU eru þegar sanngjörn og rofið er enn á endurteknu bili, þá segir bilið þér frá timeout einhvers staðar, ekki um pakkastærð. Skrifaðu bilið niður og berðu það saman við stöðu-timeout á hverju tæki á leiðinni.
Merkið er reglufesta ásamt setu sem helst nothæf innan þess bils. Aðgerðarleysi timeout slá þegar ekkert gerist; þetta slær á meðan þú skrifar.
Hvað aukagáttin gerir í raun
Setja fartölvuna og VPN-gáttina á sama LAN, með aðskildum LAN-eldvegg sem sjálfgefna gátt. Fartölvan sendir VPN-umferð til eldveggjarins, eldveggurinn sendir hana áfram til gáttarinnar, og svör gáttarinnar fara beint til baka yfir LANið á fartölvuna. Sá seinni fótur fer aldrei í gegnum eldvegginn, svo stöðutöfluna hans heldur hálfri tengingu.
Vistföngin hér að neðan endurspegla þetta fyrirkomulag:
Laptop: 192.168.50.20
LAN firewall: 192.168.50.1
WireGuard gateway: 192.168.50.10
Remote VPN subnet: 10.77.0.0/24Endurbeiningar og meðhöndlun stöðu breyta þá vinnandi handabandi í tengingu sem deyr síðar í stað strax. Töfin er stöðufærslan sem eldist eða strangari athugun sem mistekst, og þess vegna virðist bilið svo vélrænt.
Ekkert af þessu birtist í stillingum biðlarans, og þess vegna byrjar leitin að því yfirleitt í rangri skrá.
Veldu eina vísvitandi leið
Fyrir fyrirkomulagið hér að ofan fjarlægir leiðsögn fjarlæga undirnetsins beint á VPN-gáttina hálfa tenginguna:
sudo ip route add 10.77.0.0/24 via 192.168.50.10
ip route get 10.77.0.42Þetta eru dæmi um vistföng. Næsta hopp verður að vera aðgengilegt á LANinu þínu, forskeytið verður að vera fyrirhugaða fjarlæga netið, og seinni skipunin sýnir þér niðurstöðuna áður en þú treystir henni. Ef gáttin er ekki á undirnetinu þínu er þessi leið ekki lausnin sem þú vilt.
Ef eldveggurinn á að hafa eftirlit með umferð milli þessara kerfa er leiðsögn framhjá honum röng hönnun. Láttu báðar áttir fara yfir landamærin í staðinn og stilltu leiðirnar hvorri megin þannig að bakleiðin passi. Markmiðið er ein vísvitandi leið, ekki minni stöðuathugun.
athugasemdir um ósamhverfa leiðsögn Netgate lýsa sömu ósamhverfu á tengistigi og stöðuvandamálunum sem hún skapar, svo lestu þau áður en þú slakar á stöðumeðferð á heimsvísu. Tímabundin rof sem líkjast þessu tilfelli eru ekki sönnun ein og sér. Meðhöndlaðu greinina sem lýsingu á einum bilunarmáta og sannaðu síðan að þitt eigið net passi við hann áður en þú breytir alþjóðlegri stöðustefnu.
Prófaðu frá báðum endum
Lestu leið fartölvunnar að áfangastaðnum og leið áfangastaðarins til baka að fartölvunni; þetta eru tvær aðskildar ákvarðanir og líklega er aðeins önnur þeirra röng. Ping sem tekst frá gáttinni sjálfri getur falið vandamálið algjörlega, því það á uppruna sinn á vélinni sem leiðin er þegar rétt. Þú þarft báðar áttir eins og tveir endar raunverulegu setunnar sjá þær.
Eftir lagfæringuna skaltu opna SSH aftur og halda setunni opinni langt fram yfir bilið sem áður mistókst. Gerðu leiðina síðan varanlega í samþykktu netstillingunni, því einstök skipun er ekki endurræsingaráætlun og vandamálið kemur aftur við næstu endurræsingu með nýrri ráðgátu.
Hvenær ósamhverfa er í lagi
Ósamhverf leiðsögn er eðlileg í mörgum netum og er ekki brotin samkvæmt skilgreiningu. Hún verður vandamál þegar stöðusporun, þýðing eða stefna reiðir sig á að sjá leið sem hún sér ekki, og hver þeirra hefur mismunandi lækningu. Athugaðu hvað millitækið krefst í raun áður en þú hannar upp á nýtt í kringum það.
Varanlega svarið nefnir leiðirnar tvær, tækið sem þarf að sjá báðar og leiðina sem gerir það mögulegt. Ef þú getur ekki nefnt tækið hefur þú ekki fundið orsökina ennþá.