Кішкентай Linux сервері өзі орналастыратын қолданба үшін сыртқа шығатын VPN іске қосады, ал әкімші оған әлі де көрші үстелден SSH арқылы жеткісі келеді. Бұл орынды талап және әдетте портты бағыттауды, провайдер мекенжайын немесе туннельдегі тесікті қажет етпейді. Оған қажет нәрсе — VPN клиенті маршруттау кестесімен не істегенінен мұрагерлік алмай, әдейі жобаланған басқару жолы.

Төмендегі қадамдар әкімшінің сол LAN-да екенін болжайды.Қашықтан басқару — басқа жауабы бар басқа мәселе.

SSH-ты әкімшілер қолданатын мекенжайға байлаңыз

Тыңдаушыдан бастаңыз.ss -ltnp | grep :22 sshd-нің неге байланғанын көрсетеді, ал 0.0.0.0-дегі тыңдаушы туннельді қоса, әр интерфейстен қосылымдарды қабылдайды. LAN мекенжайына байлау неғұрлым тар және ниетті көрінеді етеді:ListenAddress 192.168.10.20 ішінде sshd_config, одан кейін конфигурация сынағы және қайта жүктеу. Сол мекенжайдағы қате жазу өрнектен гөрі көрінеді, өйткені мекенжай болмаған кезде sshd іске қосылудан бас тартады.

Хост кілтін тексеру мен әр пайдаланушының аутентификациясын дәл қалпында қалдырыңыз. «Бұл тек жергілікті желі» аутентификация әдісі емес, ал маршрут қысқа болғандықтан кілт тексеруін өткізіп жіберетін басқару арнасы — теріс пайдалануды күтіп тұрған арна. DHCP резерві немесе статикалық мекенжай нысанды болжамды етеді, оны сервердің жария сәйкестігіне айналдырмай.

LAN маршрутын туннельден тыс ұстаңыз

192.168.10.0/24 мекенжайы бар хостта сол префикс үшін қосылған маршрут бар, ал неғұрлым нақты маршрут сол кестедегі VPN әдепкісін жеңеді. Сондықтан туннель көтерілгенде жергілікті SSH жиі өздігінен жұмыс істей береді. Болжамай, оны тексеріңіз:ip route get 192.168.10.50 ядро қолданатын интерфейс пен бастау мекенжайын атайды, ал жауап туннель емес, LAN құрылғысы болуы керек. Тексеруді әкімшінің машинасынан да қайталаңыз, өйткені пакеттердің жететінін оның өз кестесі шешеді. Бір сымдағы екі хост қай бағыттың қолжетімді екені туралы келісе алмауы мүмкін.

Болжам екі жерде бұзылады. Саясатқа негізделген маршруттау ережесі негізгі кестеге жүгінбей тұрып, әдепкісі туннельге бағытталған кестеге трафикті жібере алады. Құлыптау немесе kill switch функциясы бар VPN клиенті де туннельге кірмейтін трафикті бөгей алады, маршруттау кестесі не десе де.

Маршрутталған басқару VLAN-дары — басқа жағдай. Егер әкімші жергілікті маршрутизатордың артында 192.168.50.0/24-де отырса, серверге сол префикс үшін 192.168.10.1 арқылы айқын маршрут қажет, және сол маршрут қайта қосылуға төтеп беруі керек. Ерекшелікті басқару префиксіне ғана қатысты ұстаңыз; жеке ауқымдарға арналған кең ерекшелік туннельдің мақсатын жояды.

Firewall ерекшелігін ереже қаншалықты тар болса, соншалықты тар етіңіз

Егер хостта firewall жұмыс істесе, SSH-қа тек басқару көзінен және тек LAN интерфейсінде рұқсат беріңіз. 22 портын барлық жерден рұқсат ететін ереже талаптан кеңірек және тексеруде ақтау қиынырақ. nftables хостында ереже интерфейс пен көз сәйкестендірілген кіріс тізбегінде болады; iptables хостында баламасы -i және -s бойынша екі сәйкестіктің жұбы. Ережені ол қызмет көрсететін әкімшілер тобымен түсіндіріңіз, келесі аудит 22 портының неге ашық екенін болжамауы үшін.

VPN клиентінің өз сүзгісін де тексеріңіз. Кейбір клиенттер дизайн бойынша жергілікті трафикті тастайтын ережелер орнатады, ал клиент деңгейіндегі тастаудың үстіндегі дұрыс firewall ережесі еш нәрсені өзгертпейді. Хосттың firewall-ын өңдеуден бұрын клиент конфигурациясын оқыңыз, өйткені қатар тұрған екі сүзгі ешқайсысына ұқсамайтын ақау туғызады.

Екі күйді де тексеріңіз

Сынақты екі рет орындаңыз: бір рет туннель қосылған кезде және бір рет ажыратылған кезде. Әр күйде тыңдаушыны, маршрутты және әкімшінің машинасынан нақты SSH кіруін растаңыз. Туннель көтерілген кезде ғана жұмыс істейтін жол жергілікті басқару жолы емес; бұл кездейсоқтық.

Содан кейін SSH сессиясы ашық кезде туннельді қайта іске қосыңыз. Тірі қалған сессия маршруттаудың тұрақты екенін дәлелдейді; үзілген сессия клиент қайта қосылу кезінде маршруттарды немесе сүзгілерді қайта жазатынын айтады, мұны оқиға алдында білген жөн, оқиға кезінде емес.

Сынақ жүргізген бастау мекенжайын жазып қойыңыз, өйткені 192.168.10.50 үшін жазылған ереже әкімшінің ноутбугі басқа ішкі желіге көшкенде үнсіз сәтсіздікке ұшырайды.

Қалпына келтіру жолын runbook-қа жазыңыз

Егер сыртқа шығатын VPN жергілікті жолды бұзса не болатынын қазір шешіңіз. Консольге қатынау, екінші басқару мекенжайы немесе клиентті тоқтатудың құжатталған процедурасы — бәрі заңды жауаптар, және олардың кез келгені кіру қажет болған сәтте мәселені табудан жақсы. Егер сервер қашықта болса, жергілікті жол жоқ, ал дұрыс жоба — ашық порт емес, жеке бекітілген қашықтан қатынау маршруты немесе бастион.

Құжаттамада екі рөлді бөлек ұстаңыз: жақын жердегі әкімші үшін жергілікті SSH және қолданба трафигі үшін сыртқа шығатын туннель. Бұл рөлдер жазылған кезде кез келгеніне болашақтағы өзгерістің тексерілетін айқын орны болады, ал келесі адам VPN-ы бар сервердің неге әлі де LAN мекенжайында жауап беретінін қайта ашуға мәжбүр болмайды.

Қатысты мақалалар