IKE ինքնություն կամ վերջնակետի հասցե՝ մի շփոթեք
FQDN տիպի IKE ինքնությունը բառացի նույնականացման արժեք է, ոչ թե հակադարձ DNS որոնում։ Առանձին պահեք վերջնակետի հասցեն, տեղական ինքնությունը և սպասվող peer-ը։
Կարդացեք FQDN ինքնություն պիտակավորված դաշտը որպես բառացի տող, ոչ թե որպես ձեր հանրային հասցեի հակադարձ DNS անվան հարցում։ strongSwan-ի վերլուծիչում դա հենց այդ է՝ տող, և այն կարդալը երբեք այն չի լուծում վերջնակետի։ Այդ փաստը ինքնին հեռացնում է ամենատարածված շեղումը, երբ դուք նույնացուցիչներ եք ընտրում peer-ի համար։ Ստորև բերված ստուգումները թույլ չեն տալիս, որ ներգրավված երեք արժեքները միաձուլվեն մեկի մեջ։
Պիտակը որոնում չէ
Մատակարարների ինտերֆեյսները թույլ են օգտագործում FQDN և hostname բառերը, և տուփի պիտակը ոչինչ չի ասում դրա հետևում եղած կոդավորման մասին։ Սարքը, որը դաշտը կոչում է Client FQDN, կարող է ուղարկել FQDN, էլփոստի ձևի տող կամ մերկ հասցե։ Վերաբերվեք տեքստին և տիպին որպես երկու առանձին որոշում և գրանցեք երկուսն էլ։
Բառացի ինքնության մեջ ոչինչ DNS չի պահանջում։ Դա պնդում է, որը ստուգում է մյուս կողմը, ոչ թե անուն, որը ցանցը պետք է լուծի։
Երեք առանձին արժեք՝ առանձին գրված
Մեկ կազմաձևման էկրանի հետևում երեք աշխատանք կա, և դրանք միավորելը թանկ սխալն է։ Մեկ արժեք է վերջնակետի հասցեն, որը որոշում է, թե ուր են գնում փաթեթները։ Մյուսը տեղական ինքնությունն է, որը ներկայացնում է այս peer-ը, իսկ երրորդը այն ինքնությունն է, որը դուք սպասում եք հեռավոր կողմից նախքան այն նույնականացնելը։ Գրեք դրանք որպես երեք տող փոփոխության տոմսում, որովհետև ավելի քիչը նկարագրում է VPN, ոչ թե հարաբերություն։
| Job | Example | What it decides |
|---|---|---|
| Where the packets go | 198.51.100.7 | The endpoint address |
| What this peer claims | gw.branch.internal | The local IKE identity |
| Who should answer | ike.hub.internal | The expected remote identity |
Օրինակի ինքնությունները պետք է ընտրվեն և լիազորվեն որպես տեղակայման մաս։ Դրանք պնդումներ են, որոնք ստուգում է նույնականացումը, ոչ թե հավատարմագրեր, որոնք ցանկացած peer-ի վստահելի կդարձնեն, ուստի հավանական տեսք ունեցող տողը ոչինչ չի լիազորում։
Տիպը արժեքի մասն է
strongSwan ինքնությունների տեղեկագիր առանձնացնում է FQDN, էլփոստի ձևի արժեքներ, IP հասցեներ և այլ կոդավորումներ, ուստի կոդավորումը նույնքան կարևոր է, որքան նիշերը։ Երկու սարք կարող են ընդունել նույն տեքստը տարբեր տիպերի ներքո և այնուամենայնիվ մերժել միմյանց։ Ծանոթագրությունը, որը գրանցում է արժեքը առանց դրա տիպի, կիսատ կազմաձև է։
Հարցրեք մատակարարին, թե սարքն իրականում որ տիպն է ուղարկում, և հաստատեք դա վերծանմամբ, ոչ թե ինտերֆեյսի պիտակով։ Գուշակված տիպը անհամապատասխանություն է, որը սպասում է հաջորդ փոփոխությանը։
Յուրաքանչյուր կողմ պետք է բավարարի մյուսին
Յուրաքանչյուր կողմի տեղական ինքնությունը պետք է անցնի մյուս կողմի նույնականացման քաղաքականությունը։ Սա նույնը չէ, ինչ մեկ տող կպցնելը երկու սարքերի յուրաքանչյուր ինքնության վանդակում, ինչը այն կարճուղին է, որը ստեղծում է կազմաձև, որը ոչ ոք չի կարող վրիպազերծել։
Վկայագրով նույնականացումը ավելացնում է իր պահանջները, որովհետև վկայագրի ինքնությունը և վստահության պայմանները կանգնած են ձեր մուտքագրած IKE ինքնության կողքին։ Միայն IKE ինքնության համընկնումը չի լիազորում վկայագրով peer-ին։
Որտեղ է DNS-ը կարևոր, և ինչ է պարտադրում ձեր տարբերակը
Բացահայտման համար օգտագործվող դարպասի hostname-ը իրոք աշխատող DNS է պահանջում, և այդ պահանջը պատկանում է վերջնակետը գտնելուն, ոչ թե մուտքագրված ինքնության որևէ հակադարձ որոնմանը։ Տոմսում առանձին պահեք երկուսը, որովհետև բացահայտման ձախողումը և ինքնության անհամապատասխանությունը հաճախորդի մատյանում նույն կերպ են կարդացվում և տարբեր տեղերում են վերանորոգվում։
Կարդացեք այն արտադրանքի և տարբերակի վերլուծիչը, որը դուք իրականում գործարկում եք, նախքան տիպ պարտադրող շարահյուսություն պատճենելը, քանի որ strongSwan-ի հին թողարկումները այլ կերպ էին վարվում, և այլ մատակարարներ ավելացնում են իրենց սահմանափակումները։ Երբ համեմատում եք երկու ծայրերը, չորս բան պահեք միասին՝ սպասվող ինքնություն, ներկայացված ինքնություն, տիպ և նույնականացման սխալ։ Այդ հավաքածուն անհամապատասխանությունը դարձնում է ապացույց՝ կարծիքի փոխարեն։