ServerAliveInterval ng SSH sa VPN: aling dulo ang nagpapadala ng probe?

Karamihan sa payo tungkol sa pagpapanatiling buhay ng sesyon ng SSH ay humihinto sa «magdagdag ng ServerAliveInterval 30» at iniiwan ang mga kapaki-pakinabang na bahagi. Ang susing salita ay timer sa panig ng client na umaandar lamang kapag tahimik ang channel, binibilang nito ang probe na walang tugon sa halip na segundo, at nakatira ito sa file kung saan nananalo ang unang tugmang halaga. Magkamali sa tatlong katangiang ito at babagsak pa rin ang malusog na sesyon ng VPN, habang ang patay ay mananatiling nakabitin.

Ang dalawang direksyon ay pag-aari ng magkaibang daemon

Ang ServerAliveInterval ay binabasa ng iyong client na ssh. Ang ClientAliveInterval ay binabasa ng sshd sa kabilang dulo at nagproprobe sa kabaligtarang direksyon, mula server patungong client. Hindi sila alias at hindi sila nagtutulungan, kaya ang pagtatakda ng isa ay walang epekto sa kilos ng kabilang dulo. Ang pagpapalit ng dalawa ang karaniwang dahilan kung bakit tila gumagana ang isang pagwawasto sa isang host at hindi sa susunod.

Pareho silang tumatanggap ng sero. Sa sero walang ipinapadala ang client, at sa panig ng server ang ClientAliveCountMax na sero ay nagpapawalang-bisa ng pagtanggal na sana ay kasunod ng mga pagsusuring walang tugon.

Ano ang pinapatunayan ng probe at ano ang hindi

Kapag lumipas ang itinakdang agwat na walang datos na dumating mula sa server, nagpapadala ang client ng maliit na kahilingan sa umiiral na naka-encrypt na channel at naghihintay ng sagot. Itinatakda ng ServerAliveCountMax kung ilan sa mga ito ang maaaring manatiling walang tugon bago putulin ang sesyon. Sa agwat na 60 at bilang na 3 sumusuko ang client pagkalipas ng mga tatlong minutong katahimikan, at ang bilang na iyon ay katangian ng iyong configuration, hindi pamantayan ng network. Iwanan ang agwat sa default nitong 0 at walang probe na ipapadala kailanman, kaya ang karaniwang client ay maaaring umupo sa patay na koneksyon nang walang hanggan.

Dahil nangyayari ang palitan sa loob ng transport na SSH, pinapatunayan ng sagot na nagbabasa at nagsusulat pa ang prosesong SSH ng kabilang dulo. Wala itong sinasabi tungkol sa programang inilunsad mo sa loob ng sesyong iyon: ang client ng database, naipasang port o mahabang script ay maaaring ma-stuck habang masayang sumasagot ang transport sa mga probe.

Ang TCPKeepAlive ay hiwalay na mekanismo isang patong sa ibaba. Kernel ang humahawak nito, hindi ito naka-encrypt, at ang kabilang dulo na ang daemon ng SSH ay stuck ay nakakasunod pa rin dito. Kaya ang probe sa antas ng SSH ang mas makabuluhang senyales kapag ang sesyon ang mahalaga sa iyo at hindi ang socket.

Ang ayos ang nagpapasya kung aling halaga ang mananatili

Inilalapat ng OpenSSH ang unang halagang nakukuha nito para sa bawat parameter, kaya ang partikular na Host block ay dapat mauna sa anumang mas malawak na block na tutugma rin. Ilagay ang mga default na may wildcard sa ilalim ng file, hindi sa itaas, at tandaan na ang Match block sa ibaba ay hindi makapagpapawalang-bisa ng halagang naitakda na. Ang sanggunian ng configuration ng client na OpenSSH ay direktang nagsasaad ng tuntunin ng unang halaga, at sulit itong basahin nang isang beses bago muling ayusin ang pinagsasaluhang configuration.

Ang mga opsyon sa command line ay nananalo sa file, na nagpapamura sa pansamantalang eksperimento:

ssh -o ServerAliveInterval=15 -o ServerAliveCountMax=4 office-shell

Upang makita kung ano talaga ang naresolba ng client at hindi ang inaakala mong isinulat mo, hilingin itong i-dump ang epektibong configuration. Nasa output ang pinagsamang halaga para sa hostname na iyon at ito ang pinakamabilis na paraan upang mahuli ang naligaw na naunang block:

ssh -G office-shell | grep -i alive

Ano ang ginagawa ng keepalive sa isang tunnel

Pinipigilan ng pana-panahong trapiko ang pag-expire ng mapping ng NAT o firewall na may estado, na tunay na pakinabang sa VPN na ang gateway ay nagtatapon ng idle na daloy pagkalipas ng ilang minuto. Ang mga probe na dumarating tuwing 60 segundo ay nagre-refresh ng mapping na iyon nang walang dalang datos ng aplikasyon.

Hindi nila kayang itayong muli ang daang nawala. Kapag nawala ang interface ng tunnel, nabibigo ang mga probe tulad ng lahat ng iba pa, at nagtatapos ang sesyon kapag naubos ang bilang. Ang pagtukoy ng buhay at pagbawi ng daan ay magkaibang problema, at ang una lamang ang maaaring i-configure sa ssh_config. Ang tunay na binibili sa iyo ng agwat at bilang ay kung gaano kabilis mapapansin ng client, at iyon ang bahaging nararanasan ng user bilang pagkabitin.

Ang mga multiplex na koneksyon ay nagdadagdag ng kulubot. Kapag kasama ang ControlMaster, pag-aari ng pangunahing koneksyon ang mga probe, at ang bagong sesyon sa ibabaw ng umiiral na pangunahin ay nagmamana ng anumang pinagkasunduan niyon. Kung ang pangunahin ng mux ay stuck, hindi muling susubukan ng pagbubukas ng ibang window ang daan.

Ang pagkumpirma ng setting mula simula hanggang dulo

Sa server, i-dump ang epektibong configuration ng daemon sa halip na basahin ang file at hulaan kung aling include ang nanalo:

sshd -T | grep -i clientalive

Pagkatapos ay panoorin ang isang tunay na sesyon na bukas ang debug na output. Nagpi-print ang client ng linyang timeout kapag naubos ang bilang, at ipinapakita ng mga timestamp sa paligid nito kung tuloy-tuloy ang katahimikan o hindi kailanman naipadala ang mga probe. Ang sesyong namamatay na walang trapiko ng probe ay karaniwang may susing salita sa block na hindi kailanman tumugma.

Sulit na magdagdag ng dalawang pagsusuri para sa anumang host na naaabot mo lamang sa pamamagitan ng tunnel: kumpirmahin na ang naresolbang agwat ay ang nilalayon mo, at kumpirmahin na ang agwat na iyon na pinarami ng bilang ay mas maikli kaysa sa idle timeout sa gateway ng VPN. Kapag mas malaki ang ikalawang bilang, tahimik na itinatapon muna ng gateway ang daloy at hindi nagkakaroon ang probe ng SSH ng pagkakataong mag-ulat ng anuman.