VPN կայքի ընդլայնում. հետևեք վերադարձի երթուղուն դարպասից այն կողմ

Մասնաճյուղից եկող թրաֆիկը վերջանում է մի դարպասի վրա, որի LAN-ը չի պարունակում այն հավելվածը, որին պետք է հասնեիք։ Սերվերը գտնվում է երկրորդ տվյալների կենտրոնում՝ ներքին կապուղու մյուս կողմում, որը VPN-ը երբեք չի կարգավորել։ Մոտակա դարպասին ևս մեկ նախադրյալ ավելացնելը այդ դեպքի համար ոչինչ չի անում, որովհետև հեռավոր դարպասը գաղտնագրման վերջնակետ է, ոչ թե վերջին երթուղիչը։ Ուղին պահանջում է առաջ ընթացող երթուղի, ընդունում հեռավոր անվտանգության սահմանին և վերադարձի որոշում նշանակակետի սեփական ցանցում։

Հեռավոր դարպասը գաղտնագրման վերջնակետ է

Դարպաս-դարպաս IPsec-ը պաշտպանում է թրաֆիկը երկու անվտանգության սարքերի միջև, և ներքին հասցեները անցնում են այդ հատվածով գաղտնագրված։ Հեռավոր դարպասից այն կողմ ստանձնում է սովորական երթուղավորումը, ներառյալ տվյալների կենտրոնների միջև գոյություն ունեցող ցանկացած քաղաքականություն։ Այսպիսով՝ պաշտպանված հատվածը ծածկում է ճանապարհի մի մասը, ոչ թե մնացածը։ Հակառակը ենթադրելն այն ուղին է, որով նախագիծը վերջանում է առողջ թունելով և անհասանելի հավելվածով։

Նկարեք ուղին երեք մասով՝ մասնաճյուղից մոտակա դարպաս, մոտակայից հեռավոր դարպաս, հեռավոր դարպասից հավելված։ Յուրաքանչյուր մաս ունի իր տերը և իր ձախողման եղանակը։

Կարդացեք թունելի քաղաքականության երկու ուղղությունները

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

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

Ավելացրեք առաջ ընթացող երթուղին և հաստատեք ընդունումը

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

ip route get 10.30.5.10 from 10.10.1.50
traceroute -n -s 10.10.1.50 10.30.5.10

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

Փորձարկեք մասնաճյուղից, ապա նորից փորձարկեք հին ուղին

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

curl -sS -m 5 http://10.30.5.10:8080/health
ping -c 3 10.20.1.1

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

Նշանակեք տեր երեք հատվածներից յուրաքանչյուրին և նշանակակետի ցանցի ներսում վերադարձի երթուղուն։ Չորս տեր ունեցող ուղին ձախողվում է նրանց միջև եղած բացերում։