Tartsa meg a helyi SSH-t, amikor a gazdagép kimenő VPN-t használ

Egy kis Linux-kiszolgáló kimenő VPN-t használ az általa hosztolt alkalmazáshoz, és az adminisztrátor továbbra is el akarja érni SSH-val a szomszédos asztaltól. Ez észszerű követelmény, és általában nem igényel sem porttovábbítást, sem szolgáltatói címet, sem lyukat az alagúton. Amire szüksége van, az egy szándékosan megtervezett felügyeleti útvonal, nem pedig az, amit a VPN-kliens a routingtáblával tett, örökölve.

Az alábbi lépések feltételezik, hogy az adminisztrátor ugyanazon a LAN-on van.A távoli felügyelet más probléma, más válasszal.

Kösse az SSH-t ahhoz a címhez, amelyet az adminisztrátorok használnak

Kezdje a figyelőnél.ss -ltnp | grep :22 megmutatja, mihez van kötve az sshd, és a 0.0.0.0 címen figyelő minden interfészről elfogad kapcsolatot, beleértve az alagutat is. A LAN-címhez kötés szűkebb, és láthatóvá teszi a szándékot:ListenAddress 192.168.10.20 a sshd_config fájlban, amit konfigurációs teszt és újratöltés követ. Az ebben a címben elkövetett elírás láthatóbb egy helyettesítő karakternél, mert az sshd megtagadja az indítást, ha a cím nem létezik.

Tartsa a gazdagépkulcs-ellenőrzést és a felhasználónkénti hitelesítést pontosan úgy, ahogy vannak. „Csak a helyi hálózat” nem hitelesítési módszer, és az a felügyeleti csatorna, amely kihagyja a kulcsellenőrzést, mert az útvonal rövid, olyan felügyeleti csatorna, amely visszaélésre vár. A DHCP-foglalás vagy a statikus cím kiszámíthatóvá teszi a célpontot anélkül, hogy a kiszolgáló nyilvános identitásává tenné.

Tartsa a LAN-útvonalat az alagúton kívül

Egy 192.168.10.0/24-es című gazdagépnek kapcsolt útvonala van ehhez az előtaghoz, és egy konkrétabb útvonal legyőzi a VPN alapértelmezett útvonalát ugyanabban a táblában. Ezért a helyi SSH gyakran magától is működik tovább, amikor az alagút feljön. Ellenőrizze ezt ahelyett, hogy feltételezné:ip route get 192.168.10.50 megnevezi az interfészt és a forrás címet, amelyet a kernel használna, és a válasznak a LAN-eszköznek kell lennie, nem az alagútnak. Ismételje meg az ellenőrzést az adminisztrátor gépéről is, mert a saját táblája dönti el, hogy a csomagok egyáltalán megérkeznek-e. Két gazdagép ugyanazon a vezetéken vitatkozhat arról, melyik irány érhető el.

A feltevés két helyen törik meg. Egy szabályalapú útválasztási szabály olyan táblába küldheti a forgalmat, amelynek alapértelmezett útvonala az alagútba mutat, mielőtt a fő táblát megnéznék. Egy zárolási vagy kill-switch funkcióval rendelkező VPN-kliens is blokkolhatja az alagútba nem belépő forgalmat, függetlenül attól, mit mond a routingtábla.

Az útválasztott felügyeleti VLAN-ok a másik eset. Ha az adminisztrátor a helyi router mögött, 192.168.50.0/24-en ül, a kiszolgálónak explicit útvonalra van szüksége ehhez az előtaghoz a 192.168.10.1-en keresztül, és ennek az útvonalnak túl kell élnie az újracsatlakozást. Tartsa a kivételt a felügyeleti előtaghoz kötve; a privát tartományokra vonatkozó széles kivétel aláássa az alagút célját.

Tegye a tűzfal-kivételt olyan szűkké, mint a szabályt

Ha a gazdagép tűzfalat futtat, csak a felügyeleti forrásból és csak a LAN-interfészen engedélyezze az SSH-t. Az a szabály, amely a 22-es portot mindenhonnan engedélyezi, szélesebb a követelménynél, és nehezebben igazolható egy felülvizsgálaton. nftables gazdagépen a szabály az inputláncba tartozik, az interfész és a forrás egyeztetésével; iptables gazdagépen a megfelelője két egyezés a -i és -s előtt. Kommentálja a szabályt a kiszolgált adminisztrátorcsoporttal, hogy a következő auditnak ne kelljen kitalálnia, miért nyitott a 22-es port.

Ellenőrizze a VPN-kliens saját szűrőjét is. Egyes kliensek tervezésüknél fogva eldobják a helyi forgalmat, és a kliensszintű eldobás fölötti helyes tűzfalszabály semmit sem változtat. Olvassa el a kliens konfigurációját, mielőtt szerkesztené a gazdagép tűzfalát, mert két soros szűrő olyan hibát okoz, amely egyikhez sem hasonlít.

Tesztelje mindkét állapotot

Futtassa a tesztet kétszer: egyszer csatlakoztatott alagúttal, egyszer pedig leválasztva. Mindkét állapotban igazolja a figyelőt, az útvonalat és egy valódi SSH-bejelentkezést az adminisztrátor gépéről. Az az útvonal, amely csak az alagút felfelé állása közben működik, nem helyi felügyeleti útvonal; ez véletlen.

Utána indítsa újra az alagutat, miközben egy SSH-munkamenet nyitva van. A túlélő munkamenet bizonyítja, hogy az útválasztás stabil; a megszakadó munkamenet azt mondja meg, hogy a kliens újracsatlakozáskor átírja az útvonalakat vagy szűrőket, amit érdemes incidens előtt tudni, nem közben.

Jegyezze fel a forráscímet, ahonnan tesztelt, mert a 192.168.10.50-hez írt szabály csendben meghibásodik, amikor az adminisztrátor laptopja más alhálózatra kerül.

Írja be a helyreállítási útvonalat a runbookba

Döntse el most, mi történik, ha a kimenő VPN megtöri a helyi útvonalat. A konzolhozzáférés, egy második felügyeleti cím vagy a kliens leállításának dokumentált eljárása mind legitim válasz, és bármelyik jobb annál, mint felfedezni a problémát abban a pillanatban, amikor be kell jelentkeznie. Ha a kiszolgáló távoli, a helyi útvonal nem létezik, és a helyes tervezés egy külön jóváhagyott távoli hozzáférési útvonal vagy egy bástya, nem pedig egy kitett nyilvános port.

Tartsa a két szerepet külön a dokumentációban: helyi SSH a közeli adminisztrátornak, és a kimenő alagút az alkalmazás forgalmának. Amikor ezek a szerepek le vannak írva, egy jövőbeli változásnak bármelyikükben nyilvánvaló ellenőrzési helye van, és a következő embernek nem kell újra felfedeznie, miért válaszol egy VPN-es kiszolgáló továbbra is a LAN-címén.