Бір жолды дәлелдейтін екі peer-лі WireGuard тестін қалай құруға болады

Бір туннель, бір жұп мекенжай, бір рұқсат етілген ресурс. Минималды WireGuard негізі әрі қарайғы forwarding, NAT немесе DNS өзгерісін көрінетін етеді.

Әдепкі маршрутты, LAN префиксін, DNS және firewall ерекшелігін көтеріп жүрген WireGuard тесті қайсысы бұзылғанын айта алмайды. Оны екі peer-ге, бір жұп мекенжайға және бір рұқсат етілген қызметке дейін әкеліңіз, сонда ақаудың жасыратын жері қалмайды. Зерігерлі негіз — сол диагностика. Оны бірінші құрыңыз; ол он бес минут алады және болжауға кетер түстен кейінгі уақытты үнемдейді.

Негіз дәлелдейтін нәрсе көпшілік күткеннен тар. Ол екі жеке бастың келісетінін, UDP тыңдау портына жететінін және бір рұқсат етілген тағайындау орны сұраныс таситынын дәлелдейді. Forwarding, NAT, LAN маршруттары мен DNS кейін біртіндеп қосылатын бөлек функциялар.

Кілттер, мекенжайлар және жалғыз endpoint

Әр жүйеде кілт жұбын жасаңыз және олардың арасында тек ашық жартыларын тасымалдаңыз. wg genkey | tee privatekey | wg pubkey > publickey — бұл құжатталған бір жолды пәрмен және жеке кілтті кейін қорғауға болатын файлда қалдырады. Туннель мекенжайларын сіздегі басқа ешбір конфигурацияда кездеспейтін диапазоннан таңдаңыз, мысалы 10.99.0.1/24 және 10.99.0.2/24. Қай мекенжай қай машинаға тиесілі екенін жазып қойыңыз, өйткені әрі қарайғы әр тексеріс осы сәйкестендіруге байланысты.

Жеке кілттер ешқашан жүрмейді. Егер тестке біреуін екінші жаққа көшіру қажет болса, тест әлдеқашан қате кеткен. Екі жүйе NAT артында болса, кемінде біреуіне қолжетімді UDP порты қажет, ал екіншісі оған сілтейтін Endpoint алып жүреді, ал ашық мекенжай мен порт 51820 туралы болжамдарыңызда емес, жазбаларыңызда болуы керек.

Басқа сыртқы портты сәйкестендіретін порт forwarding-і Endpoint оған сәйкес келгенше жақсы жұмыс істейді. Мұндағы сәйкессіздік қателер емес, үнсіздік тудырады, сондықтан сымда жөндеуге кіріспес бұрын қағазда тексерген жөн.

wg-ге тиесілі өрістер және тиесілі еместері

Негізгі өрістер жиынтығы шағын: Interface астында PrivateKey мен ListenPort, Peer астында PublicKey, AllowedIPs және Endpoint. Address пен DNS wg-нің өзіне емес, wg-quick-ке тиесілі, және бұл айырма сол конфигурация басқа құралға көшкен сәтте шайып кетеді.

[Interface]
PrivateKey = <peer-a-private>
Address = 10.99.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <peer-b-public>
AllowedIPs = 10.99.0.2/32
Endpoint = 203.0.113.10:51820

AllowedIPs бір уақытта екі жұмыс атқарады. Ол қандай тағайындау орындары туннельге кіретінін таңдайды және peer-ге келген кезде сол бастау мекенжайларын пайдалануға рұқсат береді. Сондықтан арғы жақтағы айна жазба туннель мекенжайыңызды дәл атауы керек; қате peer үшін /32 маршруттау мәселесі ретінде оқылады және авторизация мәселесіндей әрекет етеді. WireGuard жылдам бастау өріс атауларын салыстырғыңыз келсе, канондық тұжырыммен сол екі peer пішінін көрсетеді.

Белгішенің орнына handshake оқу

Интерфейсті оған иелік ететін нәрсе арқылы көтеріңіз, содан кейін күй көрсеткішін емес, күйді оқыңыз. wg show әр peer үшін соңғы handshake-ті байт санағыштарымен бірге шығарады, ал соңғы бірнеше минуттағы handshake кілттер, endpoint және UDP жолының барлығы жұмыс істеп тұрғанын білдіреді. Тек бір бағытта өсетін санағыш — өзінің жауабы, және ол ешқашан болмайтын handshake-пен бірдей ақау емес.

Екі ақау түрлі зерттеуді білдіреді. Handshake мүлдем болмауы кілттердің сәйкессіздігін, қате Endpoint-ті, бөгелген UDP-ні немесе handshake-тің өзін тастайтын firewall-ды көрсетеді. Handshake сәтті болып, деректер ешқайда кетпесе, бұл AllowedIPs-ке, туннель мекенжайында тыңдамайтын қызметке немесе портты LAN үшін қабылдап, туннель интерфейсі үшін қабылдамайтын хост firewall-ына көрсетеді. Бұлар жүйенің түрлі жартылары, және негіз ережелерді өзгертуге кіріспес бұрын оларды ажыратады.

Бір рұқсат етілген қызметті дәлелдеу, содан кейін керісінше

Екінші peer-дің туннель мекенжайына жауап беруі тиіс қызметке сұраныс жіберіңіз және ping-нен жақсырақ нәрсе таңдаңыз. ICMP жауабының жоқтығы туннель ақауы емес, хост сүзгісі болуы мүмкін, сондықтан үнсіз ping ешбір бағытты дәлелдемейді. Өзіңіз ашық деп білетін портқа TCP қосылымы немесе деректерді қайтаратын сұраныс сізге түсіндіруге болатын жауап береді.

Кері бағытты өз нәтижесі бар бөлек тест ретінде жүргізіңіз, өйткені екі бағыттың firewall мен AllowedIPs жазбалары бөлек және олар тәуелсіз сәтсіздікке ұшырауы мүмкін. Егер handshake жұмыс істеп, сұраныс істемесе, мәселе туннельде емес, деректер жолында: AllowedIPs, тыңдайтын қызмет немесе хост firewall-ы. Forwarding, NAT немесе DNS қоспас бұрын мұны түзетіңіз, әйтпесе ешқашан кінәлі болмаған функцияны жөндеуге түстен кейінгі уақытты жұмсайсыз.

Негізді эталон ретінде ұстау

Жұмыс істеп тұрған топологияны және профиль көзін қалпына келтіруге болатын жерге сақтаңыз және оларды ашық қызметке синхрондалатын кез келген қалтадан тыс ұстаңыз. Содан кейін бір уақытта бір функция қосып, әрқайсысынан кейін бастапқы сұранысты қайталаңыз: forwarding, NAT, LAN маршруты және содан кейін ғана DNS. Тестті бұзатын әрбір қосымша енді анықталады, өйткені басқа ештеңе қозғалған жоқ.

Тек белгішені жасыл ететін негіз келесі ақауға қай қосымша себеп болғаны туралы ештеңе айтпады. Жалғыз рұқсат етілген жолды эталон ретінде жұмыс істеп тұрған күйде ұстаңыз, және әрі қарайғы әр өзгеріс соған қарсы өлшенеді.

Қатысты мақалалар