Ohranite lokalni SSH, ko gostitelj uporablja odhodni VPN

Majhen strežnik Linux uporablja odhodni VPN za aplikacijo, ki jo gosti, in skrbnik ga želi še vedno doseči prek SSH z bližnje mize. To je razumna zahteva in običajno ne potrebuje ne posredovanja vrat, ne naslova ponudnika ne luknje v tunelu. Potrebuje pot upravljanja, zasnovano namerno, namesto podedovano po tem, kar je odjemalec VPN naredil s tabelo usmerjanja.

Koraki spodaj predpostavljajo, da je skrbnik v istem omrežju LAN.Oddaljeno upravljanje je druga težava z drugačnim odgovorom.

Vežite SSH na naslov, ki ga uporabljajo skrbniki

Začnite pri poslušalcu.ss -ltnp | grep :22 pokaže, na kaj je sshd vezan, in poslušalec na 0.0.0.0 sprejema povezave z vseh vmesnikov, vključno s tunelom. Vezava na naslov LAN je ožja in naredi namen viden:ListenAddress 192.168.10.20 v sshd_config, sledi preizkus konfiguracije in ponovno nalaganje. Tipkarska napaka v tem naslovu je bolj vidna kot nadomestni znak, ker sshd noče začeti, ko naslov ne obstaja.

Ohranite preverjanje ključa gostitelja in preverjanje pristnosti vsakega uporabnika natanko tako, kot sta. „To je samo lokalno omrežje“ ni metoda preverjanja pristnosti, in kanal upravljanja, ki preskoči preverjanje ključa, ker je pot kratka, je kanal upravljanja, ki čaka na zlorabo. Rezervacija DHCP ali statični naslov naredi cilj predvidljiv, ne da bi ga spremenil v javno identiteto strežnika.

Držite pot LAN zunaj tunela

Gostitelj z naslovom v 192.168.10.0/24 ima za to predpono povezano pot, in natančnejša pot premaga privzeto pot VPN v isti tabeli. Zato lokalni SSH pogosto sam od sebe deluje naprej, ko se tunel dvigne. Preverite to, namesto da predpostavite:ip route get 192.168.10.50 poimenuje vmesnik in izvorni naslov, ki bi ju uporabilo jedro, in odgovor bi moral biti naprava LAN, ne tunel. Ponovite preverjanje tudi s skrbnikovega računalnika, ker o tem, ali paketi sploh prispejo, odloča njegova lastna tabela. Dva gostitelja na istem kablu se lahko ne strinjata, katera smer je dosegljiva.

Predpostavka se zlomi na dveh mestih. Pravilo usmerjanja na podlagi pravil politike lahko pošlje promet v tabelo, katere privzeta pot kaže v tunel, preden se pregleda glavna tabela. Odjemalec VPN s funkcijo zaklepanja ali kill switch lahko tudi blokira promet, ki ne vstopi v tunel, ne glede na to, kaj pravi tabela usmerjanja.

Usmerjeni upravljalni VLAN so drug primer. Če skrbnik sedi na 192.168.50.0/24 za lokalnim usmerjevalnikom, strežnik potrebuje izrecno pot za to predpono prek 192.168.10.1, in ta pot mora preživeti ponovno povezavo. Držite izjemo posebno za upravljalno predpono; široka izjema za zasebne razpone izniči namen tunela.

Naj bo izjema požarnega zidu tako ozka kot pravilo

Če gostitelj poganja požarni zid, dovolite SSH samo z vira upravljanja in samo na vmesniku LAN. Pravilo, ki dovoli vrata 22 od povsod, je širše od zahteve in ga je teže upravičiti na pregledu. Na gostitelju nftables pravilo spada v vhodno verigo z ujemajočim se vmesnikom in virom; na gostitelju iptables je enakovredno par ujemanj na -i in -s. Komentirajte pravilo s skupino skrbnikov, ki ji služi, da naslednja revizija ne bo morala ugibati, zakaj so vrata 22 odprta.

Preverite tudi lastni filter odjemalca VPN. Nekateri odjemalci namestijo pravila, ki po zasnovi zavržejo lokalni promet, in pravilno pravilo požarnega zidu nad zavrženjem na ravni odjemalca ne spremeni ničesar. Preberite konfiguracijo odjemalca, preden uredite požarni zid gostitelja, ker dva filtra zaporedoma dasta napako, ki ni podobna nobenemu od njiju.

Preizkusite oba stanja

Zaženite preizkus dvakrat: enkrat s povezanim tunelom in enkrat z odklopljenim. V vsakem stanju potrdite poslušalca, pot in dejansko prijavo SSH z računalnika skrbnika. Pot, ki deluje le, dokler je tunel dvignjen, ni lokalna pot upravljanja; to je naključje.

Nato znova zaženite tunel, medtem ko je seja SSH odprta. Seja, ki preživi, dokazuje, da je usmerjanje stabilno; seja, ki pade, vam pove, da odjemalec pri ponovnem povezovanju prepisuje poti ali filtre, kar je vredno vedeti pred incidentom, ne med njim.

Zapišite izvorni naslov, s katerega ste preizkušali, ker pravilo, napisano za 192.168.10.50, tiho odpove, ko se skrbnikov prenosnik premakne v drugo podomrežje.

Zapišite pot obnovitve v runbook

Odločite se zdaj, kaj se zgodi, če odhodni VPN pokvari lokalno pot. Dostop do konzole, drugi naslov upravljanja ali dokumentiran postopek za ustavitev odjemalca so vsi legitimni odgovori, in kateri koli od njih je boljši kot odkriti težavo v trenutku, ko se morate prijaviti. Če je strežnik na daljavo, lokalna pot ne obstaja, in pravilna zasnova je ločena odobrena pot oddaljenega dostopa ali bastion namesto izpostavljenih javnih vrat.

Držite obe vlogi v dokumentaciji ločeni: lokalni SSH za skrbnika, ki je blizu, in odhodni tunel za promet aplikacije. Ko sta ti vlogi zapisani, ima prihodnja sprememba katere koli od njiju očiten prostor za preverjanje, in naslednji človek ni treba znova odkrivati, zakaj strežnik z VPN še vedno odgovarja na svojem naslovu LAN.