Ինչպես է հանրային վստահված սպասարկիչը VPN-ի միջոցով հասնում մասնավոր ծագման

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

Երկու մոդել, որոնք դիագրամի վրա նույնն են թվում

Նախքան որևէ բան ընտրելը գծե՛ք սլաքները։ Հանրային հրապարակման մոդելը գնում է դիտարկիչից վստահված սպասարկիչ HTTPS-ով, ապա սպասարկիչից ծագում թունելի միջոցով, և ծագումը երբեք կապ չի ընդունում ինտերնետից։ Միայն VPN-ով մոդելը գնում է հաճախորդից դարպաս, և հավելվածը հասանելի է միայն այդ ուղու ներսից։ Օգտվողի նոթբուքը գտնվում է նույն ցանցում, ինչ հավելվածը, և դա այդ մոդելի ամբողջ իմաստն է։

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

Որտեղ է կանգ առնում TLS-ը, և ինչ է այն իրականում ապացուցում

Դիտարկիչի և սպասարկիչի միջև TLS-ը պաշտպանում է այդ ցատկը և թույլ է տալիս դիտարկիչին ստուգել այն կայքը, որը մտադիր էր այցելել։ Եթե սպասարկիչը դադարեցնում է TLS-ը, հարցումը գոյություն ունի ընթեռնելի ձևով այդ գործընթացի ներսում՝ նախքան փոխանցվելը։ Երկրորդ TLS նստաշրջանը դեպի ծագում կարող է պաշտպանել հաջորդ ցատկը և առանձին ստուգել հավելվածի վերջնակետը։ Նստաշրջաններից ոչ մեկը չի որոշում, թե որ մարդը կարող է օգտվել հավելվածից։ Սպասարկիչի վրա wildcard վկայականը նույնպես չի տարածվում այդ երկրորդ ցատկի վրա։

Սա այն մասն է, որը մարդիկ սեղմում են գաղտնագրված բառի մեջ։ Գաղտնիությունը, ամբողջականությունը և սպասարկիչի ինքնությունը տրանսպորտի հատկություններ են՝ լիազորումը հավելվածի որոշում է։ Թունելի հետևում գտնվող մասնավոր հասցեն փոխում է թե ով կարող է հասնել socket-ին, ոչ թե այն, թե ով կարող է մուտք գործել հասնելուց հետո։

Վստահե՛ք փոխանցված վերնագրերին միայն սպասարկիչից

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

curl -s -o /dev/null -w '%{http_code}
' -H 'X-Forwarded-For: 203.0.113.9' http://172.20.5.40/

Եթե այդ հարցումը հաջողվում է այնպիսի հոսթից, որը սպասարկիչը չէ, ծագումը վստահում է վերնագրի, որն իրեն պետք է անտեսեր։ Ուղղե՛ք լսողին՝ նախքան հավելվածին դիպչելը։ Մերժումը շատ ավելի լավ արդյունք է, քան կեղծված հասցե կրող գրանցամատյանի տողը։

Ծագումը հասանելի պահե՛ք ճիշտ մեկ տեղից

Կապե՛ք ծագման լսողը թունելի հասցեին կամ ցանկապատե՛ք այն firewall-ով դեպի սպասարկիչը, ապա հաստատե՛ք, թե իրականում ինչն է լսում։ Wildcard կապով սկսված ծառայությունը կապեր է ընդունում հոսթի բոլոր ինտերֆեյսներում, ներառյալ այն, որը մոռացել եք, որ երթուղելի է։ Լսման աղյուսակը հիմնական ճշմարտությունն է, ոչ թե կարգավորումների այն ֆայլը, որը մտադիր էիք կիրառել։ Եթե wildcard կապը դիտավորյալ է, firewall-ը դեռ պետք է լինի այն բաղադրիչը, որը նեղացնում է այն։

ss -ltnp | grep -E ':(80|443)'

Նույն վերանայումը կատարե՛ք կառավարման ինտերֆեյսների համար, որոնք սովորական պատահական բացահայտումն են։ Ապա երկու մոդելները գրե՛ք առանձին՝ սպասարկիչի միջոցով հանրային կայքը և միայն թունելի միջոցով հասանելի կառավարման ինտերֆեյսը։ Այն նախադասությունը, թե սերվերը VPN-ի հետևում է, դրանցից ոչինչ չի ասում։