Бір бұлт қызметі үшін жергілікті TLS, SSH жіберу немесе VPN

Сұрақ екі бұлт машинасының арасында бірдеңені шифрлау керек пе дегенде емес; сұрақ қай интерфейсті шифрлап жатқаныңызда және кім кімнің жеке басын тексеретінінде. Мен бұл әңгімелерді желі диаграммасынан емес, қызметтен бастаймын, өйткені қызмет өзіне не қажет екенін біледі. Үш шекара жағдайлардың көбін қамтиды: қолданбаның өз TLS-і, SSH арқылы жіберілетін бір TCP порты және әр қатысушыға мекенжай беретін маршрутталған қабат. Олар күші бойынша емес, мәселенің қанша бөлігін қамтитыны бойынша реттеледі.

Желіден емес, қызметтен бастаңыз

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

8443 портында HTTPS ұсынып жатқан шағын ішкі API алыңыз, api.internal.example үшін сертификатпен. Хосттағы ss -ltnp оның неге байланғанын көрсетеді, ал openssl s_client -connect 127.0.0.1:8443 -verify_hostname api.internal.example сертификаттың клиент шын мәнінде қолданатын атауға жарамды екенін көрсетеді. Екеуі де сау болса, қызмет өз ағынын қорғай алады және тек қолжетімділік қалады. Бұл желі құрудан әлдеқайда кіші мәселе.

1-қадам: қызмет өзін қорғай ма?

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

Шифрлау мен қолжетімділік бөлек бақылау болып қалады, және оларды біріктіру осы нұсқаның қателесетін жері. Шектеусіз жария тыңдаушыдағы TLS қызметі әлі де кез келгеннен байланыс әрекеттерін қабылдайды, сондықтан тыңдаушы мен желі ережелері пайдалы жүктеменің қорғалғанына тәуелсіз анықталуы керек. Содан кейін тәуелділіктерді тексеріңіз, өйткені TLS үстіндегі API анықтау соңғы нүктесі, әкімші порты немесе қасындағы жаппай тасымалдау арнасы туралы ештеңе айтпайды. Олардың әрқайсысына өз жауабы қажет, ал бір қорғалмаған бауырлас бүкіл шекараны қиялға айналдыруға жеткілікті.

2-қадам: бір TCP порты бүкіл талап па?

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

Пішімі ssh -N -L 8443:127.0.0.1:8443 [email protected], ал маңызды бөлшек — мақсатты мекенжай: 127.0.0.1 алыс жақта шешіледі, сондықтан қызметке байланыс ноутбугіңізден емес, бастионнан ашылады. Жергілікті тыңдаушыны -L 127.0.0.1:8443:... ретінде тар байлаңыз, қызметті өз жергілікті желіңізге абайсызда жарияламас үшін. Сервер жағында клиенттің жақсы мінез-құлқына сенудің орнына тіркелгінің нені жібере алатынын шектеңіз. PermitOpen, AllowTcpForwarding local және әдепкі GatewayPorts no — жалпы релені нақты арнаға айналдыратын үш параметр.

Шарт екі бағытта да тар. SSH өз арнасын қорғайды, ал бастионнан басқа қолданбаға дейінгі келесі секіріс өз қорғанысын қажет етеді. Тек бастионның loopback-ында тыңдайтын қызметтің әсері басқа желі арқылы қол жеткізілетін қызметтен мүлде басқа, және жіберу мұны өзгертпейді. Туннельді олардың орнына басудың орнына қолданбаның аутентификациясы мен TLS тексерулерін ұстаңыз.

Бұл бір иесі бар бір байланыс үшін жақсы жұмыс істейді. Ауқымда бұл жүйеге айналады: жергілікті порт қақтығыстары, қадағалау, кілттерді айналдыру және қайта жүктеуден кейін жіберуді кім қайта іске қосады деген сұрақ.

3-қадам: маршруттау нақты талап па?

Бұл тізім ең кіші нұсқаның адал құны, сондықтан командалар ақырында ұмытылған бірнеше фондық пәрменді басқарылатын нәрсемен алмастырады. Алмастыру автоматты түрде VPN емес. Талап әлі де бір TCP порты болса, құжатталған иесі бар қадағаланатын жіберу қабаттан арзан пайдаланылады және көретін жолдармен сәтсіздікке ұшырайды. Әсемдікті өлшемес бұрын операциялық иелікті өлшеңіз.

Маршруттау талап болған кезде ол дұрыс жауапқа айналады. Қарапайым IP байланысы қажет бірнеше қолданба, TCP жіберуі көтере алмайтын протоколдар немесе хосттар арасында жылжитын қызметтер — бәрі бір бағытты көрсетеді.

Қабат қатысушыларға мекенжай мен маршрут береді, содан кейін нақты жұмыс басталады: қабаттаспайтын ауқымдар, маршрут иелігі, DNS, тіркеу, кері қайтарып алу және серіктес жоғалғанда не болады. Осының ешқайсысы мекенжаймен бірге келмейді. Қабатқа қабылданған серіктес те межелі жердегі әр операцияға автоматты түрде уәкілетті емес, сондықтан қызмет деңгейіндегі аутентификация қалады.

Содан кейін сізде не бар

Қалдыратын жазбаға екі нәрсе жатады. Біріншісі — клиент тексеретін жеке бас, өйткені бірдеңені іске қосу үшін атауды тексеру әлсіретілсе, осы шекаралардың әрқайсысы тыныш нашарлайды. Екіншісі — жою қадамы: қолжетімділік біткенде қай кілт, қай ереже немесе қай маршрут жоғалады және оны кім орындайды.

Шолу басталған жерінде, қызметте аяқталады. Нақты трафикті қамтитын және тексеруді көздеген серіктестерді тексеретін шекараны таңдаңыз, содан кейін қолжетімділіктің қалай жаңартылатынын, бақыланатынын және жойылатынын жазыңыз. OpenSSH анықтамалығы тар шартқа уәде бермес бұрын жіберу параметрлерін растайтын орын. Жою қадамын бір сөйлеммен сипаттай алмасаңыз, шекара мәселеден үлкен.