WireGuard толық туннелі: AllowedIPs 0.0.0.0/0 жеткіліксіз

Серіктестің AllowedIPs ішіне 0.0.0.0/0, ::/0 қою — бәрінің есте сақтайтын қадамы, және ол серіктеске қандай трафикті тасымалдауға рұқсат екенін ғана шешеді. Бұл префикстер ешқандай маршрут жасамайды, арғы жақта ештеңе жібермейді және әр қосымшаның резолверін дәл сол жерде қалдырады. Толық туннель шын мәнінде толық болуы үшін төрт бөлек нәрсе бір мезгілде орындалуы керек, және оларды төмендегі ретпен тексерген дұрыс, өйткені кешірек тексеру бұрынғыны құтқара алмайды. Төмендегі әрбір тексеру — машинадан оқуға болатын факт, қолданылды деп үміттенетін параметр емес.

Серіктес префиксі нені таңдайды, нені таңдамайды

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 қозғалатын тасымалдау санағышы бар жуықтағы қол алысуды хабарлауы керек. Маршрутсыз қол алысу менеджердің ешқашан іске қосылмағанын білдіреді, және профильді қайта өңдеу оны түзетпейді. Интерфейсті пайдаланушы қалай іске қосатын болса, солай іске қосыңыз, әйтпесе тест орналастырудың орнына сіздің shell-ді өлшейді.

Соңғы нүктені туннельден тыс ұстау

Толық туннель әрбір межені ұстайды, соның ішінде өмір сүру үшін сөйлесуі керек межені де. Менеджерлер мұны бастапқы шлюз арқылы соңғы нүктеге хост маршрутын қосу арқылы шешеді, сондықтан дұрыс конфигурацияда дерлік әрқашан бір әдейі жасалған ерекшелік болады. Конфигурацияның жартысын менеджермен, қалғанын қолмен қолдану — бұл ерекшеліктің жоғалуының кәдімгі жолы.

Егер соңғы нүкте бірнеше мекенжайға немесе сіз тасымалдамайтын отбасыға шешілетін хост атауы болса, ерекшелік нашар ескіреді және туннель кәдімгі көрінген қайта қосылудан кейін істен шығуы мүмкін. Соңғы нүктені өзіңіз басқаратын мекенжайға бекітіңіз немесе менеджер оны қайта бағалайтынын растаңыз, және әрбір желілік өзгерістен кейін хост маршрутын қайта оқыңыз.

Сол механизм толық туннель мен тұтқын порталының неге қақтығысатынын түсіндіреді. Портал туннеліңіз қазір ұстап отырған трафикті ұстап қалуды күтеді, сондықтан қонақүй мен әуежай желілерінде туннельді порталға кіргеннен кейін көтересіз, ешқашан бұрын емес.

Шлюздегі жіберу және қайту жолы

Шлюзде тасымалдайтын отбасы үшін жіберуді қосыңыз, аударған кезде 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 қосылымы не істейтіні туралы ештеңе айтпайды, ал екінші отбасын үнсіз ағызатын туннель қатты істен шығатын туннельден нашар. Әр отбасы арқылы атау сұраңыз, әр сұраныс пайдаланған интерфейсті оқыңыз және аударма санағыштарын бұрын және кейін тексеріңіз, өйткені ештеңеге сәйкес келмейтін ереже жоқ ережемен бірдей көрінеді.

Соңында, туннель тоқтағанда қалаған күйді тексеріңіз. Толық туннель өзі мәлімдеген трафик үшін жабық түрде істен шығуы керек: егер интерфейс құлап, қосымшалар физикалық байланыс арқылы үнсіз жалғаса берсе, дизайн қосымша қадамдары бар бөлінген туннель. Көзделген сәтсіздік мінез-құлқын жазыңыз, оны әдейі тексеріңіз және төрт жауапты жазып алып аяқтаңыз — қай менеджер интерфейсті көтереді, қай маршрут әдепкіні тасымалдайды, шлюзде кім жібереді және аударады, және қай резолвер жауап береді.