IPv6-ը OpenVPN թունելով՝ ուղեցույց տնային երթուղիչի համար

Նոթբուքն ունի IPv6 հասցե, թունելը բարձրացված է IPv4-ի վրա, բայց ամեն IPv6 թեստ ձախողվում է։ Կամ ավելի վատ՝ թեստը հաջողվում է, և երթևեկությունը դուրս է եկել մատակարարի ուղով՝ երբեք թունել չմտնելով։ Երկու ելքերն էլ վերադառնում են մեկ բացակայող որոշման՝ ոչ ոք երթուղիչին չի տվել նախածանց, որը նա կկարողանար երթուղել դեպի հաճախորդները։ Ուղին հաճախորդից դուրս անցնելով՝ գտնում ես, թե որ մասն է բացակայում։

Սկսեք այնտեղ, որտեղ նստած է հաճախորդը

Նայեք հաճախորդին, նախքան սերվերին դիպչելը։ ip -6 addr-ը պետք է ցույց տա թունելի հասցե լողավազանից, իսկ ip -6 route-ը՝ դեպի թունելի սարքը մատնանշող մղված նախածանցը։ Երբ հասցեն կա, բայց ուղին չկա, մղումը բացակայում է կամ հաճախորդը անտեսել է այն։ Երբ ոչ մեկը չկա, սերվերը բացարձակապես ոչինչ չի տրամադրել։

Ապա ստուգեք, թե հաճախորդը ինչ է կարծում արտաքին աշխարհի մասին։ Թունելով անցնող լռելյայն ուղին պահանջում է ամբողջ IPv6 երթևեկությունը, մինչդեռ 2000::/3-ի համար ուղին պահանջում է միայն գլոբալ unicast։ Երկուսն էլ կարող են ճիշտ լինել, և նրանք պատասխանում են արտահոսքի մասին տարբեր հարցերի։

Ամբողջովին առանց IPv6 լռելյայնի հաճախորդը ձախողում է յուրաքանչյուր հանրային թեստ, մինչ թունելն ինքը լիովին առողջ է։ Դա քաղաքականության բաց է, ոչ թե կոտրված թունել։

Ստուգեք լողավազանը, որը սերվերը իրականում կարող է երթուղել

Սերվերը կարող է տրամադրել միայն այն նախածանցից, որը նա իրականում վերահսկում է։ Եթե ISP-ն պատվիրակում է /56, պահեք մեկ /64 թունելի համար, իսկ մնացածը թողեք LAN-ին։ Որտեղ ISP-ն WAN-ի վրա տալիս է միայն մեկ /64 և այլևս ոչինչ չի երթուղում, թողեք LAN-ի նախածանցը հանգիստ և թունելին տվեք եզակի տեղական տիրույթ՝ ընդունելով, որ հաճախորդները գլոբալ ելք չեն ունենա։

Լողավազանն ու մղումը միասին են։ server-ipv6 2001:db8:80:10::/64-ը տրամադրում է հասցեներ, իսկ push "route-ipv6 2000::/3"-ը հաճախորդներին ասում է, թե ինչ ուղարկել թունել։ 2000::/3-ի մղումը ծածկում է գլոբալ unicast-ը և link-local ու multicast տիրույթները թողնում է թունելից դուրս։

Գրեք ընտրված նախածանցը տեղակայման արձանագրության մեջ։ Հաջորդ անգամ ISP-ի հանձնումը փոխողը պետք է իմանա, թե որ /64-ն է թունելն արդեն զբաղեցնում։

Միացրեք փոխանցումը երկրորդ ընտանիքի համար

IPv4 փոխանցումը չի նշանակում IPv6 փոխանցում։ Սահմանեք net.ipv6.conf.all.forwarding=1-ը և կրկնօրինակեք այն ամենը, ինչ IPv4-ի FORWARD քաղաքականությունն արդեն թույլատրում է։ Երթուղիչի վրա, որի FORWARD շղթան լռելյայն դեն է նետում, բացակայող կանոնների հավաքածուն ուղիղ մեռած թունելի տեսք ունի։

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

ip6tables -A FORWARD -i br0 -o tun0 -j ACCEPT
ip6tables -A FORWARD -i tun0 -o br0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
ip6tables -A FORWARD -i tun0 -o wan0 -j ACCEPT

Մի կողմնակի էֆեկտ բռնում է նրանց, ովքեր ի վերջո մեղադրում են թունելին։ Փոխանցումը միացնելիս միջուկը բաց է թողնում հասցեի կարգավորումը Router Advertisement-ով, եթե այլ բան չասեք, և այդպես սովորած լռելյայն ուղին անհետանում է դրա հետ։ Կամ ամրացրեք հստակ լռելյայն ուղի WAN միջերեսի վրա, կամ այնտեղ դիտավորյալ accept_ra-ը դրեք 2։ Փոփոխություններից հետո հաստատեք, որ երթուղիչը դեռ ունի դուրս գալու օգտագործելի IPv6 ուղի, նախքան հաճախորդներին նորից փորձարկելը։

Պատասխանեք հարևանների հայտնաբերմանը, երբ վերին մասը չի երթուղում

Վերին մասի սարքավորումը երբեմն պատվիրակված /64-ը համարում է իր սեփական կապուղունը և հրաժարվում է ցանկացած ենթանախածանց երթուղել դեպի VPN տուփ։ Երբ դա տեղի է ունենում, ինչ-որ բան պետք է պատասխանի հարևանային հարցումներին յուրաքանչյուր հաճախորդի հասցեի համար առանձին։

OpenVPN-ը տրամադրված հասցեն բացում է client-connect կեռիկի առաջ, այնպես որ գրառումները կարող են հետևել իրական լողավազանին՝ ձեռքով պահվող ցանկի փոխարեն։ Կեռիկը ավելացնում է ip -6 neigh add proxy $ifconfig_pool_remote_ip6 dev eth0-ը, իսկ համապատասխան client-disconnect կեռիկը հեռացնում է այն։ Առանց հեռացման proxy աղյուսակը հնանում է, և ավելի ուշ հաճախորդը կարող է ժառանգել գրառում այնպիսի հասցեի համար, որը երբեք չի ստացել։ Հաստատեք վիճակը ip -6 neigh show proxy-ով։

Վերաբերվեք proxy-ին որպես շրջանցիկ լուծում։ Թունելի /64-ի համար երթուղիչին ուղղված ստատիկ ուղին դիմանում է հաճախորդների փոփոխությանը և ընդհանրապես արտոնյալ shell կեռիկ չի պահանջում։

Հետևեք ուղուն դեպի դուրս՝ ցատկ առ ցատկ

Փորձարկեք դեպի դուրս երեք քայլով՝ նախ երթուղիչի թունելի հասցեն, ապա LAN հոսթը, և երրորդ՝ հանրային նպատակակետը traceroute6-ով։ Լողավազանը ապացուցում է առաջինը, փոխանցումն ու LAN-ի հրդեհային պատը՝ երկրորդը, իսկ վերին մասով վերադարձի ուղին՝ երրորդը։ Յուրաքանչյուր ձախողում որոնումը սեղմում է մեկ սարքի վրա՝ փոխարենը նորից բացելու ամբողջ նախագիծը։

Ուշադիր եղեք թունելի MTU-ին, քանի որ ուղու IPv6 երթուղիչները ձեր փոխարեն չեն մասնատի։ Չափից մեծ MTU-ն երևում է որպես packet-too-big սխալ և կանգնած TLS, այլ ոչ թե մաքուր ձախողում։ Սահմանեք այն բացահայտ և փորձարկեք սահմանին մոտ ծանրաբեռնվածությամբ։