Да ли IPv6 саобраћај треба да иде кроз VPN или директно?

Прошлог месеца две особе су ми тражиле супротне резултате: једна је желела да VPN покрива IPv6, друга је желела да канцеларијски штампач настави да ради. Једна рута ::/0 не може сама да обезбеди обоје. Да ли та рута припада унутрашњости тунела зависи од три услова, а први је искључује за већину комерцијалних излаза. Ако излаз не носи IPv6, усмеравање подразумеване руте тамо скрива ваш саобраћај у тунелу који нема где да га пошаље.

Три услова одлучују одговор

Подразумевана рута је један ред, ::/0, и одговара свакој IPv6 дестинацији без конкретније руте (RFC 4291). Инсталирање је лако. Одлука да ли треба своди се на три услова.

Први услов: излаз на који се повезујете има исправан IPv6 и спреман је да га проследи. Други услов: ваш клијент може да задржи пут до крајње тачке тунела, која се обично налази унутар опсега који ћете усмеравати. Трећи услов: можете да именујете локалне IPv6 дестинације које морају да остану изван тунела.

Сваки услов пада на свој начин, зато нагађање кошта целу вечер. Неуспешан први услов даје вам тишину и табелу рута која изгледа исправно. Неуспешан други услов убија руковање неколико секунди после почетка. Неуспешан трећи услов оставља исправан тунел и незадовољног колегу код штампача.

Да ли излаз заиста носи 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-у штеде следећег инжењера поновног откривања петље крајње тачке у поноћ.