Лаптопот има 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.

Третирајте го проксито како заобиколно решение. Статична патека за /64 на тунелот насочена кон рутерот преживува промени на клиентите и воопшто не бара привилегирана кука во школка.

Следете ја патеката кон надвор, скок по скок

Тестирајте кон надвор во три чекори: прво тунелската адреса на рутерот, потоа LAN домаќин и трето јавна дестинација преку traceroute6. Базенот го докажува првиот, препраќањето и LAN огнениот ѕид вториот, а повратната патека преку горниот дел третиот. Секој неуспех го стеснува пребарувањето на еден уред наместо повторно да го отвори целиот дизајн.

Внимавајте на MTU на тунелот, бидејќи IPv6 рутерите на патеката нема да фрагментираат наместо вас. Премногу голем MTU се појавува како packet-too-big грешка и заглавен TLS, а не како чист неуспех. Поставете го експлицитно и тестирајте со товар близу до границата.

Поврзани статии