Bumabagsak ang SSH sa VPN bawat minuto? Hindi keepalive ang dahilan

Kumokonekta ang SSH, gumagana nang mga isang minuto, pagkatapos ay nagyeyelo sa halos parehong agwat tuwing. Ang karaniwang paliwanag ay idle timeout, kaya binababa ng mga tao ang MTU at nagtatakda ng keepalives sa client. Ang WireGuard link na pinagtrabaahuan ko ay dumaan na sa lahat ng ito: mas maliit na MTU ng tunnel, mga setting ng client-alive, naka-configure na keepalive ng tunnel. Nagpatuloy ang mga pagbagsak nang walang pagbabago. Ang dahilan pala ay isang asymmetric na ruta ng LAN, at ang pattern ay dapat makilala dahil tinatalo nito ang bawat pag-aayos na nakabatay sa timer.

Pinatutunayan ng keepalive na handa pa ring magpadala ang iyong host. Hindi nito mapapakita sa isang device na may estado ang isang sagot na hindi kailanman dumadaan dito.

Mito: inaayos ng keepalives ang tahimik na pagbagsak

Umiiral ang SSH keepalives para sa isang gawain: pigilan ang isang bagay na nagbibilang ng katahimikan na mag-alis ng idle na sesyon. Ginagawa nila iyon nang maayos. Hindi nila nilulutas ang device na may estado na nakakita ng unang packet sa isang direksyon at pagkatapos ay hindi na nakita ang sagot, dahil wala sa ipinapadala ng client ang nagbabago kung aling interface ang ginagamit ng sagot.

Ang pagbabago ng MTU ay ang isa pang popular na pag-aayos, at may parehong paraan ng pagpalya. Ang pagbaba ng MTU ay tumutulong sa fragmentation at mga problema sa MTU ng landas, at wala itong ginagawa sa isang ruta. Kung ang iyong mga timer at MTU ay makatwiran na at ang pagbagsak ay nasa paulit-ulit na agwat pa rin, ang agwat ay nagsasabi sa iyo tungkol sa isang timeout sa isang lugar, hindi tungkol sa laki ng packet. Isulat ang agwat at ihambing ito sa mga timeout ng estado sa bawat device sa landas.

Ang tanda ay regularidad kasama ng sesyong nananatiling magagamit sa loob ng agwat na iyon. Ang idle timeouts ay tumatama kapag walang nangyayari; ito ay tumatama habang nagta-type ka.

Ano talaga ang ginagawa ng karagdagang gateway

Ilagay ang laptop at ang VPN gateway sa parehong LAN, na may hiwalay na LAN firewall bilang default na gateway. Ipinapadala ng laptop ang trapikong patungo sa VPN sa firewall, ipinapasa ito ng firewall sa gateway, at ang mga sagot ng gateway ay bumabalik nang diretso sa LAN patungo sa laptop. Ang pangalawang binti ay hindi kailanman dumadaan sa firewall, kaya ang talahanayan ng estado nito ay may kalahating koneksyon.

Ang mga address sa ibaba ay nagpapakita ng kaayusang iyon:

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

Ang mga redirect at pamamahala ng estado ay ginagawang isang koneksyong mamamatay mamaya, hindi agad, ang isang gumaganang handshake. Ang pagkaantala ay ang pagka-expire ng entry ng estado o isang mas mahigpit na pagsusuring pumapalya, kaya mukhang mekanikal ang agwat.

Wala sa mga ito ang lumalabas sa configuration ng client, kaya karaniwang nagsisimula ang paghahanap para dito sa maling file.

Pumili ng isang sinadyang landas

Para sa kaayusan sa itaas, ang pag-route ng remote subnet nang direkta sa VPN gateway ay nag-aalis ng kalahating koneksyon:

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

Ito ay mga halimbawang address. Dapat maabot ang susunod na hop sa iyong LAN, dapat ang prefix ay ang sinadyang malayong network, at ang pangalawang command ay nagpapakita ng resulta bago ka umasa dito. Kung wala ang gateway sa iyong subnet, hindi ito ang pag-aayos na gusto mo.

Kung ang firewall ay dapat magbantay sa trapiko sa pagitan ng mga sistemang iyon, ang pag-route sa paligid nito ay maling disenyo. Sa halip, hayaang tumawid ang dalawang direksyon sa hangganan at i-configure ang mga ruta sa bawat panig upang tumugma ang pabalik na landas. Ang layunin ay isang sinadyang landas, hindi mas kaunting pagsusuri ng estado.

Ang mga tala tungkol sa asymmetric na pag-route ng Netgate ay naglalarawan ng parehong asimetriya sa antas ng interface at ang mga problemang estado na nililikha nito, kaya basahin ang mga ito bago mo paluwagin ang pamamahala ng estado sa buong mundo. Ang mga timed disconnect na katulad ng kasong ito ay hindi patunay sa kanilang sarili. Ituring ang artikulo bilang paglalarawan ng isang paraan ng pagpalya, pagkatapos ay patunayan na tumutugma rito ang sarili mong network bago baguhin ang pandaigdigang patakaran ng estado.

Subukan mula sa dalawang dulo

Basahin ang ruta ng laptop patungo sa destinasyon at ang ruta ng destinasyon pabalik sa laptop; ito ay dalawang magkahiwalay na desisyon at malamang isa lang sa kanila ang mali. Ang ping na nagtagumpay mula sa gateway mismo ay maaaring itago nang lubusan ang problema, dahil nagmumula ito sa makina na tama na ang landas. Kailangan mo ang dalawang direksyon kung paano nakikita ng dalawang dulo ng aktwal na sesyon.

Pagkatapos ng pag-aayos, muling buksan ang SSH at panatilihing bukas ang sesyon nang malayo sa lumang agwat na pumapalya. Pagkatapos ay gawing permanente ang ruta sa inaprubahang configuration ng network, dahil ang isang beses na command ay hindi plano sa reboot at babalik ang problema sa susunod na reboot na may bagong misteryo.

Kung kailan ayos lang ang asimetriya

Normal ang asymmetric na pag-route sa maraming network at hindi ito sira ayon sa kahulugan. Nagiging problema ito kapag ang pagsubaybay ng estado, pagsasalin o patakaran ay nakadepende sa pagtingin sa landas na hindi nila nakikita, at bawat isa sa mga ito ay may ibang lunas. Suriin kung ano talaga ang kailangan ng gitnang device bago mag-disenyo muli sa paligid nito.

Pinapangalanan ng matibay na sagot ang dalawang landas, ang device na kailangang makita ang pareho, at ang rutang nagpapangyari nito. Kung hindi mo mapangalanan ang device, hindi mo pa natagpuan ang dahilan.