Տվյալների բազան, որն աշխատում է մինչև VPN-ի միացումը և ձախողվում դրանից հետո, հազվադեպ է հավատարմագրերի խնդիր լինում։ Ամպային ֆայրվոլները համադրում են աղբյուրի հասցեներ, և լրիվ թունելը փոխարինում է հենց այն հասցեն, որը նրանք համադրում էին։ Այն, ինչ դուք կարծում եք, թե ձեր նոթբուքն ուղարկում է, և այն, ինչ սերվերը ստանում է, միջև եղած տարբերությունը հենց ամբողջ սխալն է, և այն չափելի է մեկ քայլով։

Ինչի է վերածվում աղբյուրի հասցեն

Լրիվ թունելում յուրաքանչյուր փաթեթ դուրս է գալիս VPN դարպասով, ուստի սերվերը տեսնում է դարպասի ելքային հասցեն, ոչ թե ձեր տնային կապը։ Եթե ուղու վրա կա ուղղորդ պրոքսի, հասնում է հենց նրա հասցեն։ Երկուսն էլ օրինական աղբյուրներ են, և ոչ մեկը ձեր սկզբնական կանոնի հասցեն չէ։

Azure SQL-ի սերվերի մակարդակի և տվյալների բազայի մակարդակի ֆայրվոլի կանոնները համադրում են այն հաճախորդի հասցեն, որը հասնում է տրամաբանական սերվերին, և լրիվ թունելից հետո դա ելքային հասցեն է։ Մեկ հասցե թույլատրող AWS անվտանգության խումբը նույն կերպ է վարվում։ Փաթեթը դեն է նետվում նույնականացումից առաջ, ուստի ստացված սխալը նման է ցանցի խափանման, ոչ թե թույլտվության խնդրի։ Հենց դրա համար են մարդիկ սկսում գաղտնաբառեր վերականգնել։

Որտեղ է որոշվում թույլատրվածների ցանկը

Կարդացեք այն կանոնը, որը համապատասխանում է ձախողվող ուղուն, ոչ թե այն կանոնը, որը հիշում եք, թե ստեղծել եք։ Նկատեք դրա շրջանակը, պորտը, արձանագրությունը և այն, արդյոք այն գնահատվում է ինքնության ցանկացած ստուգումից առաջ։

Այնուհետև որոշեք, թե որ շերտն է օրինականորեն տիրապետում այդ որոշմանը։ Հասցեի կանոնը պատասխանում է, թե որտեղից է գալիս երթևեկությունը։ Մասնավոր վերջնակետը պատասխանում է, թե արդյոք ծառայությունը հասանելի է մասնավոր ուղով ընդհանրապես։ Բաժանված թունելի բացառությունը պատասխանում է, թե որ նպատակակետերն են շրջանցում թունելը։ Դրանք փոխանակելի չեն, և յուրաքանչյուրը տարբեր կերպ է ձախողվում, երբ թունելը փոխվում է։

Երեք վերանորոգում, երեք շերտ

Ստորև յուրաքանչյուր տարբերակ ուղղում է հոսքը տարբեր պատճառով, և սխալ ընտրությունը ստեղծում է կապ, որն աշխատում է մինչև դարպասի հաջորդ փոփոխությունը։

RepairLayer it changesWhat it does not fix
Add the egress address to the ruleSource address matchingNothing about routing, and it breaks when the egress moves
Use a private endpointWhether the service is reached privatelyA client that still resolves the public name
Add a split-tunnel exceptionWhich flows bypass the tunnelAn expired credential or a wrong password

Ելքային հասցեի ավելացումը ամենափոքր փոփոխությունն է և ամենափխրունը, քանի որ նոր դարպասը կամ այլ տարածաշրջանը լուռ անվավերացնում է այն։ Փաստաթղթավորեք հասցեն թունելի սահմանման կողքին, որպեսզի երկուսը շարժվեն միասին։ Ժամանակավոր լայն տիրույթը ախտորոշում է, ոչ թե վերանորոգում, այն թողնելը տեղում հենց այն ճանապարհն է, որով ներքին ծառայությունները մնում են բաց։

Ինչու կառավարվող հարթակը չի կարող միանալ թունելին

Ծրագրային հարթակները, ինչպիսիք են Heroku-ն, AppHarbor-ը կամ CloudBees-ը, ձեր կոդը գործարկում են միջավայրում, որտեղ tun կամ tap սարք չկա և այն ստեղծելու իրավասություն էլ չկա։ Նրանց ներգնա մոդելը HTTP է, ոչ թե կամայական լսող սոկետ։ VPN երկուական ֆայլ տեղափոխող buildpack-ը դեռ տեղ չունի ինտերֆեյսը դնելու։ Աշխատունակ ձևերն են ստատիկ ելքային հասցեն, որը տվյալների բազան կարող է թույլատրել, հարթակի առաջարկած մասնավոր կապի արտադրանքը կամ DMZ-ում գտնվող պրոքսին, որին հասնում են HTTPS-ով։

Այդ պրոքսին մուտքի ուղի է՝ իր սեփական նույնականացմամբ և գրանցմամբ։ Այն հարթակին ձեր VPN-ի անդամ չի դարձնում, և այդպես նկարագրելը ստեղծում է կանոններ, որոնք ոչ ոք չի կարող աուդիտ անել։

Ստուգեք այն հաճախորդից, որը ձախողվել է

Կրկին միացեք և կրկնեք հաճախորդի ճշգրիտ ուղին։ Ստուգեք այն աղբյուրի հասցեն, որը գրանցում է ծառայությունը, այն երթուղին, որը հաճախորդն ընտրում է տվյալների բազայի անվան համար, և փաստացի հարցման արդյունքը՝ հենց այդ հերթականությամբ։ Դարպասից արված թեստը ապացուցում է, որ դարպասն աշխատում է, ինչը երբեք կասկածի տակ չի եղել։ Եթե կապն այժմ նույնականացվում է, իսկ հարցումը դեռ ձախողվում է, մնացած խնդիրը տվյալների բազայի թույլտվությունն է։

Վերանայեք այս կանոնները ամեն անգամ, երբ թունելը փոխվում է։ Փոխարինված դարպասը կամ նոր ելքային տիրույթը կոտրում է ուղին առանց հավելվածի կարգավորումների որևէ փոփոխության։

Առնչվող հոդվածներ