Säilita kohalik SSH, kui host kasutab väljuvat VPN-i

Väike Linuxi server kasutab väljuvat VPN-i rakenduse jaoks, mida ta majutab, ja administraator tahab selleni ikkagi SSH-ga kõrvalt laualt jõuda. See on mõistlik nõue ja tavaliselt ei vaja see ei portide suunamist, teenusepakkuja aadressi ega auku tunnelis. Vaja on haldusteed, mis on meelega kavandatud, mitte päritud sellest, mida VPN-i klient marsruutimistabeliga tegi.

Järgmised sammud eeldavad, et administraator on samas LAN-is.Kaughaldus on teine probleem teise vastusega.

Siduge SSH aadressiga, mida administraatorid kasutavad

Alustage kuulajast.ss -ltnp | grep :22 näitab, millega sshd on seotud, ja kuulaja aadressil 0.0.0.0 võtab vastu ühendusi igalt liideselt, sealhulgas tunnelist. LAN-i aadressiga sidumine on kitsam ja teeb kavatsuse nähtavaks:ListenAddress 192.168.10.20 failis sshd_config, millele järgneb konfiguratsiooni test ja uuesti laadimine. Kirjaviga selles aadressis on nähtavam kui metamärk, sest sshd keeldub käivitumast, kui aadressi ei ole olemas.

Jätke hosti võtme kontroll ja kasutajapõhine autentimine täpselt selliseks, nagu need on. „See on ainult kohalik võrk“ ei ole autentimismeetod, ja halduskanal, mis jätab võtme kontrollimise vahele, sest marsruut on lühike, on halduskanal, mis ootab kuritarvitamist. DHCP reservatsioon või staatiline aadress muudab sihtmärgi ettearvatavaks, muutmata seda serveri avalikuks identiteediks.

Hoidke LAN-i marsruut tunnelist väljas

Hostil, mille aadress on 192.168.10.0/24, on selle prefiksi jaoks ühendatud marsruut, ja täpsem marsruut võidab VPN-i vaikimisi marsruudi samas tabelis. Seetõttu jätkab kohalik SSH sageli iseenesest töötamist, kui tunnel üles tuleb. Kontrollige seda, selle asemel et eeldada:ip route get 192.168.10.50 nimetab liidese ja lähteaadressi, mida kernel kasutaks, ja vastuseks peaks olema LAN-i seade, mitte tunnel. Korrake kontrolli ka administraatori masinast, sest selle enda tabel otsustab, kas paketid üldse kohale jõuavad. Kaks hosti samal juhtmel võivad olla eriarvamusel, milline suund on kättesaadav.

Eeldus puruneb kahes kohas. Poliitikal põhinev marsruutimisreegel võib saata liikluse tabelisse, mille vaikimisi marsruut osutab tunnelisse, enne kui põhitabelit vaadatakse. VPN-i klient, millel on lukustus- või kill-switch-funktsioon, võib samuti blokeerida liiklust, mis tunnelisse ei sisene, olenemata sellest, mida marsruutimistabel ütleb.

Marsruuditud haldus-VLAN-id on teine juhtum. Kui administraator istub kohaliku ruuteri taga aadressil 192.168.50.0/24, vajab server selle prefiksi jaoks selgesõnalist marsruuti läbi 192.168.10.1 ja see marsruut peab üle elama taasühenduse. Hoidke erand spetsiifilisena haldusprefiksi jaoks; lai erand privaatsete vahemike jaoks nurjab tunneli eesmärgi.

Tehke tulemüüri erand sama kitsaks kui reegel

Kui hostil töötab tulemüür, lubage SSH-d ainult haldusallikast ja ainult LAN-i liidesel. Reegel, mis lubab porti 22 kõikjalt, on nõudest laiem ja ülevaatusel raskemini põhjendatav. nftables-hostil kuulub reegel sisendketti koos liidese ja allika sobitamisega; iptables-hostil on ekvivalent -i ja -s kahe sobivuse paar. Komment eerige reeglit administraatorite rühmaga, keda see teenindab, et järgmine audit ei peaks oletama, miks port 22 avatud on.

Kontrollige ka VPN-i kliendi enda filtrit. Mõned kliendid paigaldavad reeglid, mis disaini järgi loobuvad kohalikust liiklusest, ja korrektne tulemüürireegel kliendi tasandi loobumise peal ei muuda midagi. Lugege kliendi konfiguratsiooni enne hosti tulemüüri muutmist, sest kaks filtrit järjestikku tekitavad tõrke, mis ei sarnane kummagagi neist.

Testige mõlemat olekut

Käivitage test kaks korda: üks kord tunneliga ühendatud ja üks kord ühendamata olekus. Mõlemas olekus kinnitage kuulaja, marsruut ja tegelik SSH-sisselogimine administraatori masinast. Tee, mis töötab ainult siis, kui tunnel on üleval, ei ole kohalik haldustee; see on juhus.

Seejärel taaskäivitage tunnel, kui SSH-seanss on avatud. Seanss, mis jääb püsima, tõestab, et marsruutimine on stabiilne; seanss, mis katkeb, ütleb teile, et klient kirjutab taasühendamisel marsruudid või filtrid ümber, mida tasub teada enne juhtumit, mitte selle ajal.

Pange kirja lähteaadress, kust testisite, sest aadressile 192.168.10.50 kirjutatud reegel ebaõnnestub vaikselt, kui administraatori sülearvuti liigub teise alamvõrku.

Kirjutage taastamistee runbooki

Otsustage kohe, mis juhtub, kui väljuv VPN rikub kohaliku tee. Konsoolipääs, teine haldusaadress või dokumenteeritud protseduur kliendi peatamiseks on kõik legitiimsed vastused ja ükskõik milline neist on parem kui probleemi avastamine hetkel, mil peate sisse logima. Kui server on kaugel, kohalikku teed ei ole ja õige lahendus on eraldi kinnitatud kaughaldustee või bastion, mitte avatud avalik port.

Hoidke kaks rolli dokumentatsioonis lahus: kohalik SSH administraatorile, kes on lähedal, ja väljuv tunnel rakenduse liiklusele. Kui need rollid on kirja pandud, on tulevasel muudatusel kummaski neist selge koht, kus seda kontrollida, ja järgmine inimene ei pea uuesti avastama, miks VPN-iga server vastab endiselt oma LAN-i aadressil.