Պե՞տք է արդյոք IPv6 երթևեկությունը անցնի VPN-ով, թե ուղիղ։
Որոշեք՝ արդյոք ::/0-ը պատկանում է թունելի ներսում, երեք պայմանով՝ ելքի աջակցություն, վերջնակետի հասանելիություն և միայն տեղական ցանցեր։
Անցյալ ամիս երկու մարդ ինձնից հակառակ արդյունքներ խնդրեցին՝ մեկը ուզում էր, որ IPv6-ը ծածկվի VPN-ով, մյուսը ուզում էր, որ գրասենյակի տպիչը շարունակի աշխատել։ Մեկ երթուղին ::/0 ինքնուրույն չի կարող ապահովել երկուսն էլ։ Արդյոք այդ երթուղին պատկանում է թունելի ներսում, կախված է երեք պայմանից, և առաջինը բացառում է այն առևտրային ելքերի մեծ մասի համար։ Եթե ելքը IPv6 չի կրում, ապա լռելյայն երթուղին այնտեղ ուղղելը թաքցնում է ձեր երթևեկությունը թունելում, որտեղ այն ուղարկելու տեղ չկա։
Երեք պայման են որոշում պատասխանը
Լռելյայն երթուղին մեկ տող է՝ ::/0, և այն համապատասխանում է ցանկացած IPv6 նպատակակետի, որը չունի ավելի կոնկրետ երթուղի (RFC 4291)։ Այն տեղադրելը հեշտ է։ Արդյոք պետք է դա անեք, հանգում է երեք պայմանի։
Առաջին պայման՝ ելքը, որին միանում եք, ունի աշխատող IPv6 և պատրաստ է այն փոխանցել։ Երկրորդ պայման՝ ձեր հաճախորդը կարող է պահպանել ուղին դեպի թունելի վերջնակետ, որը սովորաբար գտնվում է այն միջակայքում, որը պատրաստվում եք ուղղորդել։ Երրորդ պայման՝ կարող եք անվանել տեղական IPv6 նպատակակետերը, որոնք պետք է մնան թունելից դուրս։
Յուրաքանչյուր պայման ձախողվում է յուրովի, և դրա համար գուշակելը արժենում է մի ամբողջ երեկո։ Ձախողված առաջին պայմանը ձեզ տալիս է լռություն և երթուղիների աղյուսակ, որը ճիշտ է թվում։ Ձախողված երկրորդ պայմանը սպանում է ձեռքսեղմումը սկսելուց մի քանի վայրկյան անց։ Ձախողված երրորդ պայմանը թողնում է աշխատող թունել և դժգոհ գործընկեր տպիչի մոտ։
| What you see | Decision |
|---|---|
| Exit answers IPv6 probes, no local IPv6 devices to protect | Route ::/0 into the tunnel |
| Exit answers IPv6 probes, printer or NAS reachable by a global address | Route ::/0, then give those prefixes a route of their own |
| Exit is IPv4-only inside the tunnel | Do not route ::/0; block IPv6 on the client |
Endpoint is reached over IPv6 and sits inside ::/0 | Install a host route for the endpoint first |
Արդյոք ելքը իրականում կրում է IPv6։
IPv6 հասցեով թունելային միջերեսը ոչինչ չի ապացուցում մյուս կողմի մասին։ Շատ առևտրային պրոֆիլներ ներսից միայն IPv4 են՝ սերվերը ձեզ տալիս է v4 հասցե և դեն նետում մնացածը։ Դրա վրա տեղադրեք լռելյայն երթուղի AllowedIPs-ից, և միջուկը հաճույքով IPv6 կուղարկի մի միջերես, որի գործընկերը երբեք չի տեսնում այն։
Փորձարկեք հաճախորդից, մինչ թունելը բարձրացված է։ ping -6 -c 3 2001:4860:4860::8888 և ip -6 route get 2001:4860:4860::8888 տարբեր հարցերի են պատասխանում՝ արդյոք պատասխանը վերադառնում է, և որ սարքն է ընտրել միջուկը։ Երբ երկրորդը անվանում է ձեր թունելը, իսկ առաջինը ոչինչ չի վերադարձնում, խնդիրը ելքի մեջ է, ոչ թե երթուղու։
Եթե դուք ինքներդ եք վարում ելքը, հաճախորդի թեստը կարող է անցնել, և ուղին այնուամենայնիվ կհասնի փակուղու։ Հաստատեք, որ դարպասում միացված է net.ipv6.conf.all.forwarding=1, և որ դրա հրամուրն ընդունում է թունելից փոխանցված փաթեթները։ Ճիշտ ուղղորդված փաթեթը դեպի ելք, որը հրաժարվում է փոխանցել, հաճախորդի կողմից երևում է ուղիղ որպես երթուղավորման սխալ։
Կարո՞ղ է հաճախորդը պահպանել իր ուղին դեպի վերջնակետ։
Սա այն դեպքն է, որը բռնեց ինձ մի նոթբուքում, որի WireGuard վերջնակետը միայն IPv6 էր։ Վերջնակետի հասցեն սովորական գլոբալ հասցե է, ուստի այն ընկնում է ::/0-ի ներսում։ Ուղղորդեք ամբողջ նախածանցը միջերես, և ձեռքսեղմման փաթեթները կքշեն իրենց այն թունելը, որը դեռ փորձում են կառուցել։ Թունելը երբեք չի բարձրանում, և հաճախորդի արտադրանքի մեջ ոչինչ չի ասում, թե ինչու։
wg-quick-ը լուծում է դա Linux-ում։ Այն երթուղիները բխեցնում է AllowedIPs-ից, տեղադրում է դրանք իր աղյուսակում և ավելացնում քաղաքականության կանոն, որպեսզի վերջնակետ ուղղված երթևեկությունը սկզբում լուծվի հիմնական աղյուսակով՝ suppress_prefixlength 0 կանոնը, որը գտնում եք ip -6 rule-ում։ Այդ պատճառով wg-quick up-ը հաջողվում է այնտեղ, որտեղ ձեռքով գրված ip -6 route add default dev wg0-ը կտրում է ձեզ։
Ստուգեք երկու վիճակներն էլ ip -6 route get <endpoint-v6>-ով՝ թունելը բարձրացնելուց առաջ և հետո։ Եթե պատասխանը փոխվում է դեպի ձեր թունելային սարքը, դուք հեռացրել եք այն ուղին, որն անհրաժեշտ է թունելին։ Երբ ինքներդ եք գրում երթուղիները, ավելացրեք հոսթի երթուղի դեպի վերջնակետ սկզբնական դարպասով, կամ միացեք վերջնակետին IPv4-ով և թողեք IPv6-ը բեռնվածությանը։
Ինչ պետք է մնա թունելից դուրս։
Ավելի կոնկրետ երթուղիները հաղթում են լռելյային, ուստի կապի վրա գտնվող նախածանցը կամ սեփական երթուղի ունեցող ULA միջակայքը շարունակում է աշխատել առանց լրացուցիչ ջանքի։ Սա է այն հանգիստ պատճառը, թե ինչու են այդքան շատ ամբողջական թունելով IPv4 կարգավորումներ գոյատևում՝ LAN նախածանցները ավելի կոնկրետ են, քան լռելյայնը, և երբեք չեն մտնում թունել։
Այն կոտրվում է, երբ տեղական սարքը հասանելի է գլոբալ հասցեով, ինչը նորմալ է տպիչի համար, որին նույն երթուղիչը տվել է հանրային նախածանց, NAS-ի կամ հեռուստացույցի համար։ Այդ հասցեները համապատասխանում են ::/0-ին և ուրիշ ոչնչի, ուստի դրանք մյուս ամեն ինչի հետ տեղափոխվում են թունել և անհետանում։
Որոշեք ըստ նպատակակետի, ոչ ըստ արձանագրության։ Եթե երկու-երեք տեղական հոսթ կարևոր են, տվեք նրանց նախածանցերին ելք ֆիզիկական միջերեսով, կամ հանեք դրանք բանակցված հավաքածուից։ Եթե ցանկը շարունակում է աճել, ազնիվ պատասխանը IPv6-ի համար գրավոր բացառությունների ցանկով բաժանված թունելն է, ոչ թե լռելյայն երթուղի, որը դուք անընդհատ կարկատում եք։
Եթե պատասխանը ոչ է, արգելափակեք այն
IPv6-ը առանց երթուղու թողնելը նույնը չէ, ինչ այն հանգիստ թողնելը։ Աշխատող IPv6 լռելյայն ունեցող հոսթը շարունակում է օգտագործել այն, մինչ թունելը կրում է IPv4, ուստի երթևեկությունը դուրս է գալիս VPN-ի կողքով, և յուրաքանչյուր ծառայություն, որ նախընտրում է IPv6, տեսնում է ձեր իրական հասցեն։ Դա արտահոսք է, ոչ թե բաժանված թունել։
Ընտրեք մեկը և գրեք, թե որն ընտրեցիք։ Ուղղորդեք լռելյայնը և ընդունեք վերևի փոխզիջումները, կամ անջատեք IPv6-ը թունելի տևողության համար։ Նախածանցը AllowedIPs-ից բաց թողնելը ինքնին բավարար չէ, քանի որ օպերացիոն համակարգը պահում է իր սեփական լռելյայնը։ Linux-ում կոպիտ տարբերակը sysctl -w net.ipv6.conf.all.disable_ipv6=1-ն է․ ավելի նուրբ տարբերակը IPv6-ը թունելից դուրս է գցում հրամուրի կանոնով։ Հեռախոսների հաճախորդներն ունեն IPv6-ի արգելափակման բացահայտ անջատիչ, որն անում է նույն աշխատանքը։
Ստուգեք այն որպես արտահոսք
Բարձրացրեք թունելը և կարդացեք վիճակը՝ անջատիչին վստահելու փոխարեն։ ip -6 route show default-ը պետք է ցույց տա մեկ լռելյայն, և ip -6 route get-ը ձեր LAN-ից դուրս նպատակակետի համար պետք է անվանի թունելային սարքը։ Կրկնեք երկուսն էլ անջատումից հետո՝ թունելը գերազանցող լռելյայնը հենց այն սխալն է, որը դուք փնտրում էիք։
Ապա փորձարկեք հակառակ ուղղությունը։ Տեղական ցանցի հոսթից հասեք հաճախորդին նրա տեղական IPv6 հասցեով։ Եթե դա դադարում է աշխատել, երրորդ պայմանը երբեք չի կատարվել, ինչ էլ որ այդ պահին պնդեր երթուղիների աղյուսակը։
Գրեք արդյունքը այնտեղ, որտեղ կգտնի հաջորդ մարդը՝ որ նախածանցերն են մնում տեղական, ինչու, և ինչ է անում հաճախորդը անջատումից հետո։ Runbook-ի երկու տողը փրկում է հաջորդ ինժեներին կեսգիշերին վերջնակետի հանգույցը նորից հայտնաբերելուց։