OpenVPN туннели аркылуу IPv6: үй маршрутизатору боюнча сереп
IPv6 туннель маршрутизатор маршруттай албаган префиксти бергенде өлөт же агып кетет. Клиент, пул, кайра багыттоо, proxy NDP жана кайтуу жолун кезеги менен карап чыгыңыз.
Ноутбукта IPv6 дареги бар, туннель IPv4 үстүндө көтөрүлгөн, бирок ар бир IPv6 сынагы ийгиликсиз аяктайт. Же андан да жаманы: сынак ийгиликтүү өтүп, трафик туннелге такыр кирбей провайдердин жолу менен чыгып кетти. Эки жыйынтык тең бир жетишпеген чечимге алып барат: эч ким маршрутизаторго кардарларды көздөй багыттай алган префикс берген жок. Жолду кардардан сыртка карай жүрсөңүз, кайсы бөлүк жетишпей жатканы табылат.
Кардар турган жерден баштаңыз
Серверге тийүүдөн мурун кардарды караңыз. ip -6 addr пулдан туннель дарегин, ал эми ip -6 route туннель түзмөгүнө багытталган жиберилген префиксти көрсөтүшү керек. Дарек бар, бирок маршрут жок болсо, жиберүү жетишпейт же кардар аны этибарга алган эмес. Экөө тең жок болсо, сервер такыр эч нерсе бөлгөн эмес.
Андан кийин кардардын сырткы дүйнө тууралуу эмне деп ойлойорун текшериңиз. Туннель аркылуу өткөн демейки маршрут бардык IPv6 трафигин талап кылат, ал эми 2000::/3 үчүн маршрут глобалдык unicast гана талап кылат. Экөө тең туура болушу мүмкүн жана алар агым тууралуу ар башка суроолорго жооп берет.
IPv6 демейки маршруту такыр жок кардар туннелдин өзү толук соо болсо да ар бир ачык сынактан өтпөйт. Бул саясаттагы кемчилик, бузулган туннель эмес.
Сервер чындап маршруттай алган пулду текшериңиз
Сервер өзү чындап көзөмөлдөгөн префикстен гана бөлө алат. Эгер провайдер /56 делегацияласа, туннель үчүн бир /64 калтырып, калганын LAN үчүн калтырыңыз. Провайдер WAN боюнча бир гана /64 берип, андан ары эч нерсе маршруттабаса, LAN префиксин тынч калтырып, туннелге уникалдуу жергиликтүү диапазон бериңиз, кардарларда глобалдык чыгуу болбой турганын кабыл алыңыз.
Пул жана жиберүү чогуу жүрөт. server-ipv6 2001:db8:80:10::/64 даректерди бөлөт, ал эми push "route-ipv6 2000::/3" кардарларга туннелге эмне жиберүү керектигин айтат. 2000::/3 жиберүү глобалдык unicast-ты камтыйт жана link-local менен multicast диапазондорун туннелден тыш калтырат.
Тандалган префиксти жайгаштыруу жазуусуна жазыңыз. Кийинки жолу провайдер өткөрүп берүүсүн өзгөрткөн адам туннель кайсы /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 катары көрүнөт. Аны ачык коюп, чекке жакын жүктөм менен сынаңыз.