Пун тунел WireGuard: AllowedIPs 0.0.0.0/0 није довољно

Уписивање 0.0.0.0/0, ::/0 у AllowedIPs партнера је корак који сви памте, и он одлучује само који саобраћај партнер сме да носи. Ови префикси не стварају руте, ништа не прослеђују на другој страни и остављају резолвер сваке апликације тачно тамо где је био. Четири одвојене ствари морају да важе истовремено да би пун тунел био заиста пун, и најбоље их је проверавати по реду испод, јер каснија провера не може да спасе ранију. Свака провера испод је чињеница која се може прочитати са машине, а не подешавање за које се надате да је примењено.

Шта префикс партнера бира, а шта не

AllowedIPs је истовремено селектор и дозвола. Он локалној страни каже која одредишта смеју да се шаљу овом партнеру, а страни која прима каже које изворне адресе овај партнер сме да представи. То је цео посао. Ништа у том опису не ствара руту на домаћину, не укључује прослеђивање на удаљеној страни и не дотиче разрешавање имена.

Зато конфигурација може да изгледа потпуна и да се понаша као подељени тунел. Префикс каже да би партнер прихватио све; табела рутирања домаћина одлучује шта тамо заиста стиже, а пролаз одлучује да ли нешто излази. Ниједна од те три одлуке не живи у одељку партнера.

Рутирати клијента, не само списак партнера

Менаџери као што је wg-quick програмирају табелу рутирања домаћина уместо вас, зато се два идентична конфигурациона фајла понашају различито зависно од тога како се интерфејс подигао. Минимални профил је довољно кратак да се прочита у једном даху:

[Interface]
Address = 10.8.0.2/32
DNS = 10.8.0.1

[Peer]
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = vpn.example.net:51820

Посао носе два детаља. Поље Address је један префикс домаћина, а не подмрежа за коју клијент мисли да је поседује, и управо менаџер претвара подразумевани AllowedIPs у стварну подразумевану руту. Подигните исти фајл помоћу ip link и wg setconf и неће се појавити ниједна рута, што изгледа као покварен тунел, а заправо је здрав тунел са прескоченим кораком рутирања. Приручник wg-quick документује рутирање и Table понашање које ти менаџери додају.

Читајте резултат, а не фајл: ip route get 1.1.1.1 треба да именује интерфејс тунела, а wg show треба да пријави недавно руковање са бројачем преноса који се креће. Руковање без руте значи да се менаџер никада није покренуо, и поновно уређивање профила то неће поправити. Покрените интерфејс онако како ће га корисник покренути, иначе тест мери вашу љуску уместо распоређивања.

Држати крајњу тачку изван тунела

Пун тунел хвата сваку одредиште, укључујући и ону са којом мора да разговара да би постојао. Менаџери то решавају додавањем руте домаћина за крајњу тачку кроз оригинални пролаз, зато исправна конфигурација готово увек садржи један намерни изузетак. Примена половине конфигурације менаџером, а друге половине ручно, уобичајен је начин на који тај изузетак нестаје.

Ако је крајња тачка име домаћина које се разрешава на неколико адреса, или на породицу коју не носите, изузетак лоше стари и тунел може да откаже после поновног повезивања које је изгледало рутински. Причврстите крајњу тачку на адресу коју контролишете, или потврдите да је менаџер поново процењује, и поново прочитајте руту домаћина после сваке промене мреже.

Исти механизам објашњава зашто се пун тунел и заробљени портал свађају. Портал очекује да пресретне саобраћај који ваш тунел сада хвата, зато на хотелским и аеродромским мрежама тунел подижете после пријаве на портал, никада пре тога.

Прослеђивање и повратни пут на пролазу

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

sysctl net.ipv4.ip_forward net.ipv6.conf.all.forwarding
ip route get 1.1.1.1 from 10.8.0.2

Претрага се извршава на пролазу, а не на клијенту, иначе ћете читати другу табелу рутирања. Ако именује погрешан интерфејс, или пријави да нема руте, онда ниједна промена на страни клијента неће створити излаз на интернет. Када пролаз преводи адресе клијената на излазу, одговор зависи од тог стања превођења, зато правило мора да постоји за оба смера тока, а не само за одлазни.

DNS и стање квара, тестирани одвојено

Сам протокол не подешава резолвер ниједне апликације. wg-quick примењује линију DNS кроз интеграцију резолвера дистрибуције, контејнери и прегледачи са својим стековима могу то да игноришу, и зато име може да откаже док тунел беспрекорно носи пакете. Тестирајте именом домаћина, а не адресом, и забележите који сервер је одговорио уместо да претпоставите да је то био онај из профила.

Породице адреса су одвојен тест са одвојеним одговором. Подразумевана рута за v4 не говори ништа о томе шта ће урадити v6 веза неке апликације, а тунел који тихо отиче другу породицу гори је од оног који гласно отказује. Питајте име кроз сваку породицу, прочитајте интерфејс који је сваки захтев користио, и проверите бројаче превођења пре и после, јер правило које се ни са чим не поклапа изгледа исто као правило које недостаје.

На крају, тестирајте стање које желите када се тунел заустави. Пун тунел треба да откаже затворено за саобраћај који тврди: ако интерфејс падне и апликације тихо наставе преко физичке везе, дизајн је подељени тунел са додатним корацима. Запишите предвиђено понашање при квару, проверите га намерно, и завршите бележењем четири одговора — који менаџер подиже интерфејс, која рута носи подразумевану, ко прослеђује и преводи на пролазу, и који резолвер одговара.