SSH ik minūti atkrīt VPN? Vainīgs nav keepalive

SSH pieslēdzas, strādā apmēram minūti un pēc tam katru reizi iesalst apmēram tajā pašā intervālā. Ierastais skaidrojums ir dīkstāves taimauts, tāpēc cilvēki samazina MTU un iestata klienta keepalive. WireGuard savienojums, pie kura strādāju, jau bija izgājis cauri visam tam: mazāks tuneļa MTU, client-alive iestatījumi, konfigurēts tuneļa keepalive. Pārrāvumi turpinājās nemainīgi. Cēlonis izrādījās asimetrisks LAN maršruts, un šo modeli ir vērts atpazīt, jo tas pārspēj jebkuru taimeru balstītu labojumu.

Keepalive pierāda, ka tavs resursdators joprojām ir gatavs sūtīt. Tas nevar likt stāvokli glabājošai ierīcei redzēt atbildi, kas tai nekad neiet cauri.

Mīts: keepalive izlabo klusu pārrāvumu

SSH keepalive pastāv vienam uzdevumam: neļaut kaut kam, kas skaita klusumu, aizvākt dīkstāvē esošu sesiju. To tie dara labi. Tie neatrisina stāvokli glabājošas ierīces gadījumu, kas redzēja pirmo paketi vienā virzienā un pēc tam nekad neredzēja atbildi, jo nekas no klienta sūtītā nemaina, kuru saskarni izmanto atbilde.

MTU maiņa ir otrs populārais labojums, un tam ir tāds pats atteices režīms. MTU samazināšana palīdz fragmentācijai un ceļa MTU problēmām, un maršrutam tā neko nedara. Ja tavi taimeri un MTU jau ir saprātīgi un pārrāvums joprojām notiek atkārtotā intervālā, intervāls stāsta par taimautu kaut kur, nevis par paketes izmēru. Pieraksti intervālu un salīdzini to ar stāvokļa taimautiem katrā ceļa ierīcē.

Pazīme ir regularitāte kopā ar sesiju, kas paliek lietojama šajā intervālā. Dīkstāves taimauti sit, kad nekas nenotiek; šis sit, kamēr tu raksti.

Ko papildu vārteja patiešām dara

Novieto klēpjdatoru un VPN vārteju tajā pašā LAN, ar atsevišķu LAN ugunsmūri kā noklusējuma vārteju. Klēpjdators sūta VPN vērsto trafiku ugunsmūrim, ugunsmūris pārsūta to vārtejai, un vārtejas atbildes atgriežas tieši caur LAN pie klēpjdatora. Tā otrā kāja nekad neiet caur ugunsmūri, tāpēc tā stāvokļa tabula tur pusi savienojuma.

Zemāk esošās adreses atspoguļo šo izkārtojumu:

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

Pārvirzīšana un stāvokļa apstrāde pēc tam pārvērš strādājošu rokasspiedienu savienojumā, kas mirst vēlāk, nevis uzreiz. Kavēšanās ir stāvokļa ieraksta novecošana vai stingrākas pārbaudes neizdošanās, tāpēc intervāls izskatās tik mehānisks.

Nekas no tā neparādās klienta konfigurācijā, tāpēc tā meklēšana parasti sākas nepareizajā failā.

Izvēlies vienu apzinātu ceļu

Iepriekš minētajam izkārtojumam attālā apakštīkla maršrutēšana tieši uz VPN vārteju novērš pusi savienojuma:

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

Tās ir piemēru adreses. Nākamajam lēcienam jābūt sasniedzamam tavā LAN, prefiksam jābūt paredzētajam attālajam tīklam, un otrā komanda parāda rezultātu, pirms uz to paļaujies. Ja vārteja nav tavā apakštīklā, šis maršruts nav tas labojums, ko vēlies.

Ja ugunsmūrim jāuzrauga trafiks starp šīm sistēmām, maršrutēšana ap to ir nepareizs dizains. Tā vietā ļauj abiem virzieniem šķērsot robežu un konfigurē maršrutus katrā pusē tā, lai atgriešanās ceļš sakristu. Mērķis ir viens apzināts ceļš, nevis mazāk stāvokļa pārbaudes.

Netgate piezīmes par asimetrisko maršrutēšanu apraksta to pašu saskarnes līmeņa asimetriju un stāvokļa problēmas, ko tā rada, tāpēc izlasi tās, pirms vispārīgi atslābini stāvokļa apstrādi. Šim gadījumam līdzīgi laika pārrāvumi paši par sevi nav pierādījums. Uztver rakstu kā viena atteices režīma aprakstu, pēc tam pierādi, ka tavs tīkls tam atbilst, pirms maini globālo stāvokļa politiku.

Pārbaudi no abiem galiem

Izlasi klēpjdatora maršrutu uz galamērķi un galamērķa maršrutu atpakaļ uz klēpjdatoru; tie ir divi atsevišķi lēmumi, un, visticamāk, tikai viens no tiem ir nepareizs. Ping, kas izdodas no pašas vārtejas, var pilnībā paslēpt problēmu, jo tas nāk no mašīnas, kuras ceļš jau ir pareizs. Tev vajadzīgi abi virzieni tā, kā tos redz īstās sesijas abi gali.

Pēc labojuma atver SSH vēlreiz un turi sesiju atvērtu krietni ilgāk par intervālu, kas iepriekš neizdevās. Pēc tam padari maršrutu pastāvīgu apstiprinātajā tīkla konfigurācijā, jo vienreizēja komanda nav restartēšanas plāns un problēma atgriezīsies nākamajā restartā ar jaunu mistēriju.

Kad asimetrija ir kārtībā

Asimetriska maršrutēšana daudzos tīklos ir normāla, un pēc definīcijas tā nav salauzta. Tā kļūst par problēmu, kad stāvokļa izsekošana, tulkošana vai politika ir atkarīga no ceļa, ko tās neredz, redzēšanas, un katram no tiem ir atšķirīgs līdzeklis. Pārbaudi, ko vidējā ierīce patiešām prasa, pirms pārprojektē ap to.

Noturīgā atbilde nosauc abus ceļus, ierīci, kurai jāredz abi, un maršrutu, kas to padara iespējamu. Ja nevari nosaukt ierīci, tu vēl neesi atradis cēloni.