Երկակի կույտի VPN լողավազաններ՝ երկու ընտանիքների հասցեավորումը strongSwan-ում

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

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

Երկու ընտանիք ներսում, մեկ ուղի դրսում

Արտաքին կապը IKE է UDP-ի վրա, և նրան անհրաժեշտ է մեկ հասանելի հասցեների ընտանիք այնտեղից, որտեղ գտնվում է հաճախորդը։ Ներքին IPv6 հասցեն չի պահանջում IPv6 ունեցող մատակարար, քանի որ ներքին փաթեթը բեռն է արտաքինի ներսում։ Շատ աշխատող տեղակայումներ IPv6 նախածանցներ են տեղափոխում միայն IPv4 ունեցող վերին կապով։

Այն, ինչ արտաքին ուղին իսկապես սահմանափակում է, հասանելիությունն ու NAT-ի հաղթահարումն է։ Եթե դարպասը հայտարարում է միայն IPv4 հասցե, ապա միայն IPv6 ցանցում գտնվող հաճախորդը ընդհանրապես չի կարող միանալ, անկախ նրանից, թե ինչ լողավազաններ եք կարգավորել։ Արտաքին ընտանիքը որոշեք ձեր հաճախորդների բազմությամբ, ոչ թե ներքին հասցեային պլանով։

Տվեք հաճախորդին հասցե յուրաքանչյուր ընտանիքում

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

pools {
  pool4 { addrs = 10.90.0.0/24 }
  pool6 { addrs = fd42:90::/64 }
}
connections {
  private-access {
    version = 2
    pools = pool4, pool6
    local  { auth = pubkey  certs = gateway.pem  id = vpn.example.com }
    remote { auth = pubkey  cacerts = ca.pem  vips = 0.0.0.0, :: }
    children {
      private { local_ts = 10.60.0.0/16, fd42:60::/48  remote_ts = dynamic }
    }
  }
}

Արժեքը vips հայցում է հասցե յուրաքանչյուր ընտանիքից, և լողավազանների ցանկը որոշում է, թե որտեղից են գալիս այդ հասցեները։ Փաստաթղթերը strongSwan-ի վիրտուալ IP-ների մասին ընդգրկում են բազմաթիվ հայցեր և լողավազանների բաշխում, ներառյալ այն կետը, որ կոնկրետ հասցե հայցող հաճախորդը միայն նախապատվություն է արտահայտում, որը պատասխանողը կարող է վերացնել։ Մի կառուցեք մուտքի կանոն, որը ենթադրում է, թե հաճախորդը միշտ ստանում է նույն արժեքը։

Ստեղծեք ձեր սեփական եզակի տեղական նախածանցը՝ օրինակը պատճենելու փոխարեն։ Երկու կազմակերպություն, որոնք երկուսն էլ fd42::/16 ներդնեն այն, կհայտնաբերեն բախումը առաջին իսկ փոխկապակցման ժամանակ, և դա ախտորոշելը հաճելի չէ։

Ընտրիչները նկարագրում են նպատակակետեր, ոչ աղբյուրներ

Երեխա SA-ի տեղական երթևեկության ընտրիչները ասում են, թե որ պաշտպանված ցանցերն են դարպասի հետևում, իսկ հեռավոր ընտրիչները նկարագրում են, թե հաճախորդն ինչ կարող է օգտագործել որպես աղբյուր։ Վիրտուալ լողավազանի հասցեն պատկանում է այդ քաղաքականության աղբյուրի կողմին. այն նպատակակետերի ցանկում դնելը կարգավորման տարածված սխալ ընթերցում է։

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

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

DNS-ը և պատասխանի ուղին որոշում են՝ ավարտված է թվում, թե ոչ

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

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

Ստուգեք երկու ընտանիքներն էլ, նախքան ավարտված անվանելը

Բեռնվող կարգավորումը աշխատող կարգավորում չէ։ Կարդացեք դեյմոնի հաղորդած վիճակը, հաստատեք լողավազանների բաշխումը, ապա նայեք այն ուղիներին, որոնք հաճախորդն իրականում տեղադրել է։

swanctl --list-sas
swanctl --list-pools
ip -6 addr show scope global
ip -6 route get fd42:60::10

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

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