Säilytä paikallinen SSH, kun isäntä käyttää lähtevää VPN:ää

Pieni Linux-palvelin käyttää lähtevää VPN:ää isännöimänsä sovelluksen puolesta, ja ylläpitäjä haluaa yhä päästä siihen SSH:lla viereiseltä työpöydältä. Se on kohtuullinen vaatimus, eikä se yleensä vaadi portinohjausta, palveluntarjoajan osoitetta tai reikää tunneliin. Se tarvitsee hallintapolun, joka on suunniteltu tarkoituksella eikä peritty siitä, mitä VPN-asiakas teki reititystaululle.

Alla olevat vaiheet olettavat, että ylläpitäjä on samassa LAN-verkossa.Etähallinta on eri ongelma, jolla on eri vastaus.

Sido SSH osoitteeseen, jota ylläpitäjät käyttävät

Aloita kuuntelijasta.ss -ltnp | grep :22 näyttää, mihin sshd on sidottu, ja kuuntelija osoitteessa 0.0.0.0 hyväksyy yhteyksiä kaikilta liitäntärajapinnoilta, myös tunnelista. LAN-osoitteeseen sitominen on kapeampi ja tekee aikomuksen näkyväksi:ListenAddress 192.168.10.20 tiedostossa sshd_config, jota seuraa kokoonpanon testaus ja uudelleenlataus. Kirjoitusvirhe siinä osoitteessa on näkyvämpi kuin jokerimerkki, koska sshd kieltäytyy käynnistymästä, kun osoitetta ei ole.

Pidä isäntäavaimen tarkistus ja käyttäjäkohtainen todennus täsmälleen sellaisina kuin ne ovat. „Se on vain paikallinen verkko“ ei ole todennusmenetelmä, ja hallintakanava, joka ohittaa avaimen tarkistuksen, koska reitti on lyhyt, on hallintakanava, joka odottaa väärinkäyttöä. DHCP-varaus tai staattinen osoite tekee kohteesta ennustettavan muuttamatta sitä palvelimen julkiseksi identiteetiksi.

Pidä LAN-reitti tunnelin ulkopuolella

Isännällä, jonka osoite on 192.168.10.0/24, on yhdistetty reitti sille etuliitteelle, ja tarkempi reitti voittaa VPN:n oletusreitin samassa taulussa. Siksi paikallinen SSH usein jatkaa toimimista itsestään, kun tunneli nousee. Tarkista se sen sijaan, että olettaisit:ip route get 192.168.10.50 nimeää liitäntärajapinnan ja lähdeosoitteen, jota ydin käyttäisi, ja vastauksen pitäisi olla LAN-laite, ei tunneli. Toista tarkistus myös ylläpitäjän koneelta, koska sen oma taulu päättää, saapuvatko paketit ylipäätään. Kaksi isäntää samalla kaapelilla voivat olla eri mieltä siitä, mikä suunta on tavoitettavissa.

Oletus rikkoutuu kahdessa paikassa. Käytäntöpohjainen reitityssääntö voi lähettää liikennettä tauluun, jonka oletus osoittaa tunneliin, ennen kuin päätaulua katsotaan. VPN-asiakas, jossa on lukitus- tai kill switch -toiminto, voi myös estää liikennettä, joka ei mene tunneliin, riippumatta siitä, mitä reititystaulu sanoo.

Reititetyt hallinta-VLANit ovat toinen tapaus. Jos ylläpitäjä istuu osoitteessa 192.168.50.0/24 paikallisen reitittimen takana, palvelin tarvitsee eksplisiittisen reitin sille etuliitteelle osoitteen 192.168.10.1 kautta, ja sen reitin on kestettävä uudelleenyhdistäminen. Pidä poikkeus hallintaetuliitteen erityisenä; laaja poikkeus yksityisille alueille kumoaa tunnelin tarkoituksen.

Tee palomuurin poikkeuksesta yhtä kapea kuin sääntö

Jos isännällä on palomuuri, salli SSH vain hallintalähteestä ja vain LAN-liitännällä. Sääntö, joka sallii portin 22 kaikkialta, on vaatimusta laajempi ja vaikeampi perustella katselmuksessa. nftables-isännällä sääntö kuuluu syöteketjuun liitäntä ja lähde täsmättyinä; iptables-isännällä vastaava on pari täsmäytystä -i ja -s. Kommenteeraa sääntöä hallintaryhmällä, jota se palvelee, jotta seuraava auditointi ei joudu arvaamaan, miksi portti 22 on auki.

Tarkista myös VPN-asiakkaan oma suodatin. Jotkin asiakkaat asentavat sääntöjä, jotka suunnittelun mukaan pudottavat paikallista liikennettä, eikä oikea palomuurisääntö asiakastason pudotuksen päällä muuta mitään. Lue asiakkaan kokoonpano ennen isännän palomuurin muokkaamista, koska kaksi suodatinta sarjassa tuottavat vian, joka ei muistuta kumpaakaan niistä.

Testaa molemmat tilat

Aja testi kahdesti: kerran tunnelin ollessa yhdistettynä ja kerran irrotettuna. Vahvista kussakin tilassa kuuntelija, reitti ja todellinen SSH-kirjautuminen ylläpitäjän koneelta. Polku, joka toimii vain tunnelin ollessa ylhäällä, ei ole paikallinen hallintapolku; se on sattumaa.

Käynnistä sitten tunneli uudelleen, kun SSH-istunto on auki. Istunto, joka selviää, todistaa reitityksen olevan vakaa; istunto, joka katkeaa, kertoo asiakkaan kirjoittavan reittejä tai suodattimia uudelleen yhdistettäessä, mikä on syytä tietää ennen tapahtumaa eikä sen aikana.

Kirjaa lähdeosoite, josta testasit, koska osoitteelle 192.168.10.50 kirjoitettu sääntö epäonnistuu hiljaisesti, kun ylläpitäjän kannettava siirtyy toiseen aliverkkoon.

Kirjoita palautumispolku runbookiin

Päätä nyt, mitä tapahtuu, jos lähtevä VPN rikkoo paikallisen polun. Konsolipääsy, toinen hallintaosoite tai dokumentoitu menettely asiakkaan pysäyttämiseksi ovat kaikki hyväksyttäviä vastauksia, ja mikä tahansa niistä on parempi kuin ongelman löytäminen sillä hetkellä, kun sinun on kirjauduttava sisään. Jos palvelin on etäinen, paikallista polkua ei ole, ja oikea suunnittelu on erillinen hyväksytty etäkäyttöpolku tai bastion eikä altistettu julkinen portti.

Pidä kaksi roolia erillään dokumentaatiossa: paikallinen SSH lähellä olevalle ylläpitäjälle ja lähtevä tunneli sovelluksen liikenteelle. Kun nuo roolit on kirjoitettu, tulevalla muutoksella kummassa tahansa on ilmeinen paikka tarkistaa, eikä seuraavan henkilön tarvitse löytää uudelleen, miksi VPN:ää käyttävä palvelin vastaa yhä LAN-osoitteessaan.