Хост сыртка чыгуучу VPN иштеткенде жергиликтүү SSH сактаңыз
Сыртка чыгуучу туннель жергиликтүү администрацияны өзү менен алып кетиши шарт эмес. Угуучуну байлаңыз, LAN маршрутун сактаңыз, эрежени тарылтыңыз жана эки абалды тең текшериңиз.
Кичинекей 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 дарегинде жооп берерин кайра ачууга мажбур болбойт.