Целосен тунел WireGuard: AllowedIPs 0.0.0.0/0 не е доволно
0.0.0.0/0 и ::/0 само избираат што пренесува партнерот. Менаџерот на клиентот, препраќањето на портата, DNS и политиката при грешка сѐ уште треба да се конфигурираат.
Ставањето 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 врската на некоја апликација, а тунел што тивко ја истекува втората фамилија е полош од оној што гласно откажува. Прашајте име низ секоја фамилија, прочитајте го интерфејсот што го користел секое барање, и проверете ги бројачите на преведување пред и потоа, бидејќи правило што не се совпаѓа со ништо изгледа исто како правило што недостига.
На крајот, тестирајте ја состојбата што ја сакате кога тунелот запира. Целосниот тунел треба да откаже затворено за сообраќајот што го тврди: ако интерфејсот падне и апликациите тивко продолжат преку физичката врска, дизајнот е поделен тунел со дополнителни чекори. Запишете го предвиденото однесување при грешка, проверете го намерно, и завршете со запишување на четирите одговори — кој менаџер го подига интерфејсот, која рута го носи стандардот, кој пренесува и преведува на портата, и кој резолвер одговара.