Անջատե՞լ IPv6-ը VPN արտահոսքը շտկելու համար. ավելի լավ է որոշել քաղաքականությունը
Link-local հասցեն արտահոսք չէ, և գլոբալ IPv6 երթուղին նույնպես։ Նախ ընտրեք արգելափակել, տեղափոխել կամ ձեռք չտալ։
IPv6 տիրույթի հասցե է հայտնվում փորձարկման էջում, թունելն ակնհայտորեն այն չի տեղափոխում, և ինտերնետի ամենահայտնի խորհուրդը IPv6-ը ամենուր անջատելն է։ Այդ հրամանը իսկապես լռեցնում է վահանակը։ Այն նաև հեռացնում է արձանագրություն, որից կարող է կախված լինել մուտքի ցանցը, և ձեզ թողնում է առանց պատկերացման՝ հասցեն իրական արտահոսք էր, link-local միջերեսի հասցե, թե resolver, որն անում է իր գործը։ Երեք պայման է որոշում ճիշտ կառավարումը, և դրանցից միայն մեկն է տանում արգելափակման։
Որոշեք, թե գործիքն իրականում ինչ է չափել
Ամենատարածված կեղծ ահազանգը link-local հասցեն է, որը սկսվում է fe80:-ով և գոյություն ունի յուրաքանչյուր IPv6-ընդունակ միջերեսում՝ անկախ այն բանից՝ մեքենան IPv6-ով հասնում է ինտերնետ, թե ոչ։ Այն երևում է միջերեսների ցանկերում և որոշ հավելվածների ախտորոշումներում, և ոչինչ չի ասում ձեր երթևեկության ուղու մասին։
Երկրորդ կեղծ ահազանգը եզակի տեղական հասցեն է fc00::/7-ում, որը մասնավոր տիրույթ է և օգտագործվում է ցանցի ներսում։ Գործիքը, որը տպում է հոսթի բոլոր հասցեները, հաճույքով այն կցուցադրի հանրայինի կողքին։ Ով արագ է կարդում, դա արտահոսք է անվանում և հետո մեկ ժամ ծախսում գոյություն չունեցող խնդրի վրա։
Երրորդը բոլորովին կեղծ ահազանգ չէ։ Գլոբալ հասցեն, որը թունելից դուրս հասնում է ինտերնետ, հենց իրական արտահոսքն է, և արժե այն չափել նախքան որևէ բան որոշելը։
ip -6 addr show scope global
ip -6 route show default
curl -6 -sS --max-time 6 https://ifconfig.coԵթե առաջին հրամանը տպում է գլոբալ հասցե, իսկ երրորդը վերադարձնում է հանրային IPv6 հասցե, որը թունելինը չէ, դուք ունեք իրական ուղի թունելից դուրս։ Եթե առաջինը տպում է միայն link-local գրառումներ, արտահոսք, որ շտկվի, երբեք չի եղել։
Երեք պայման է որոշում կառավարումը
Որոշումը «IPv6-ը լավ է» կամ «IPv6-ը վատ է» չէ։ Որոշումը այն է, թե երեք իրավիճակներից որում եք, և յուրաքանչյուրն ունի տարբեր ճիշտ պատասխան՝ տարբեր գնով, եթե սխալվեք։
| Situation | Correct control | Cost if you disable IPv6 instead |
|---|---|---|
| Exit has no IPv6, host does | Block IPv6 deliberately in the tunnel policy | Same visible result, no documentation of intent |
| Exit carries IPv6, host leaks | Route IPv6 into the tunnel and verify | You lose IPv6 reachability entirely |
| Access network is IPv6-only | Change nothing; use the tunnel's IPv6 | Machine loses connectivity completely |
Առաջին տողն այն է, ինչ մարդիկ սովորաբար նկատի ունեն, և դա օրինական է։ Հաճախորդը, որի ելքը IPv6 աջակցություն չունի, չպետք է լուռ բաց թողնի հոսթի սեփական IPv6 երթևեկությունը, որովհետև դա փաստաթղթավորված կրկնակի ստեկի արտահոսքն է։ Խնդիրը այն որպես հայտարարված քաղաքականություն արգելափակելն է, ոչ թե միջուկում արձանագրություն անջատելը։ Տեսանելի արդյունքը նույնն է, և հետագայում ստուգելի է միայն մեկը։
Երրորդ տողն այն տեղն է, որտեղ ընդհանուր խորհուրդն ակտիվորեն վնասակար է դառնում։ Բջջային օպերատորները և որոշ տնային կապեր վարում են IPv6-only ցանցեր՝ IPv4 նպատակակետերի համար թարգմանությամբ։ Այնտեղ հեռացրեք IPv6-ը և կհեռացնեք ցանցի առաջարկած միակ տրանսպորտը, ինչը շատ ավելի վատ խափանում է ստեղծում, քան այն, ինչ դուք վերացնում էիք։
Եթե ելքը IPv6 չունի, արգելափակեք այն դիտավորությամբ
Նախընտրեք հաճախորդի սեփական մեխանիզմը, որովհետև այն գործում է ճիշտ այնքան, քանի դեռ թունելը բարձր է, և վերադառնում է, երբ այն ընկնում է։ OpenVPN ունի դրա համար ընտրանք, և iptables-ն ունի համարժեք կանոն այլ հաճախորդների համար։
block-ipv6
ip6tables -A OUTPUT -o eth0 -j REJECT --reject-with ipv6-port-unreachableՀրահանգը պատկանում է պրոֆիլին, կանոնը՝ firewall-ին, որը կարող եք վերանայել և հեռացնել։ Երկուսն էլ ձախողվում են փակ վիճակում, ինչը ցանկալի է, և երկուսն էլ երևում են կոնֆիգուրացիայի diff-ում, ինչը չի կարելի ասել մեկնարկային սկրիպտում թաղված միջուկի sysctl-ի մասին։
Գրանցեք, թե ինչու է այն այնտեղ։ Առանց մեկնաբանության արգելափակման կանոնը կհեռացնի հաջորդ մարդը, ում IPv6 պետք է անկապ բանի համար, և հետո արտահոսքը հանգիստ կվերադառնա։
Եթե ելքը տեղափոխում է IPv6, երթուղավորեք այն և փորձարկեք երկու ընտանիքները
IPv6 տեղափոխելը լավագույն պատասխանն է, երբ սերվերը դա աջակցում է, և դա շատ ավելի դժվար չէ։ Պահանջն այն է, որ թունելի միջերեսն ունենա հասցե այդ ընտանիքում, և դրա լռելյայն երթուղին ուղղված լինի թունելի ներս, ոչ թե ֆիզիկական միջերեսից դուրս։
ip -6 route get 2606:4700:4700::1111
ip -6 route show default
curl -6 -sS --max-time 6 https://ifconfig.co
curl -4 -sS --max-time 6 https://ifconfig.coԵրթուղու որոնումը վճռական փորձարկումն է. եթե այն նշում է թունելի միջերեսը, IPv6 երթևեկությունը տեղափոխվում է։ Երկու curl կանչերն այնուհետև հաստատում են, թե ինչ է տեսնում յուրաքանչյուր ընտանիք, և դրանց համեմատությունն է ապացուցում, որ երկու ուղիներն էլ այժմ դուրս են գալիս նույն ելքով։
Մի կանգնեք հաջող կապակցման վրա։ Կրկին միացրեք թունելը և ստուգեք նորից, որովհետև հրող IPv6 երթուղին կարող է կորչել վերականգնման ժամանակ, եթե սերվերն այն ուղարկում է միայն սկզբնական կոնֆիգուրացիայում։ Ապա ստուգեք մեկ բացառված նպատակակետ, որովհետև split-tunnel կանոններն են այն տեղը, որտեղ երկու ընտանիքներն ամենից հաճախ տարբերվում են։
Եթե մուտքի ցանցը միայն IPv6 է, ձեռք չտաք
Որոշ ցանցեր տալիս են միայն IPv6 և ակնկալում, որ սարքը IPv4 ծառայություններին կհասնի օպերատորի կողմի թարգմանության մեխանիզմով։ Նման մեքենայում IPv6-ն անջատելը անվտանգության բարելավում չէ. այն հեռացնում է ամեն ինչի տանող միակ ուղին։ Դա ինքներդ ձեզ պատճառած խափանում է հանուն փորձարկման արդյունքի, որ ոչ մեկին պետք չէր։
Այս սխալի ախտանիշը առանձնահատուկ և տհաճ է. թվում է՝ թունելը կառուցվում է, անունների լուծումն աշխատում է, և ոչինչ չի բեռնվում։ Եթե դա տեսնեք IPv6 փոփոխությունից հետո, անմիջապես վերականգնեք կարգավորումը և շարունակեք ախտորոշումը այլ տեղ։
Ինչ էլ ընտրեք, պահեք որոշումը բացահայտ պրոֆիլում կամ firewall-ում, կապեք այն այն բանի հետ, ինչ ելքը իրականում աջակցում է, և նշեք կրկնակի ստեկի վարքը, որը նկարագրում է RFC 7359-ի կրկնակի ստեկի քննարկումը ։ Հայտարարված արգելափակումը քաղաքականություն է։ Անջատված արձանագրությունը շրջանցում է, որը ոչ ոք չի կարող աուդիտ անել, և փորձարկման էջից դրանք նույնն են թվում։