WireGuard қол алысуы жұмыс істейді, бірақ интернет жоқ: пакетті бақылаңыз
Қол алысу тек кілттер мен қолжетімділікті дәлелдейді. AllowedIPs-тен бастап жіберу, NAT және қайтару маршруты арқылы бір пакетті бақылап, оның қай жерде тоқтайтынын көріңіз.
Туннель қосулы, wg show жуырдағы қол алысуды көрсетеді, сервердің туннель мекенжайына ping жасай аласыз, ал одан әрі ештеңе жауап бермейді. Бірінші ой кілттерді қайта жасау немесе конфигурацияны қайта бөлісу болады. Бұл жолдың жұмыс істейтіні дәлелденген бөлігін ғана өзгертеді.
Аяқталған қол алысу екі жақтың кілттер туралы келіскенін, UDP соңғы нүктеге жететінін және крипто маршруттау пакетті қабылдайтынын айтады. Ол пакеттің кейін серверден шыға алатыны туралы ештеңе айтпайды.
Сондықтан болжаудың орнына бір пакетті бақылаңыз. Ол өлуі мүмкін төрт орын бар, және әрқайсысы басқа із қалдырады.
Қол алысу шын мәнінде нені дәлелдейді
WireGuard — Noise қол алысуымен сессия орнататын, содан кейін серіктес үшін пакеттерді шифрлайтын UDP протоколы. wg show бірнеше секундтық қол алысуды және өсіп келе жатқан жіберу санағышын көрсеткенде, соңғы нүкте, кілттер және серіктестің ашық кілті бәрі дұрыс.
Ол дәлелдемейтіні: клиентіңіз интернетке бағытталған трафикті интерфейске мүлдем жібере ме, сервер оны жіберуге дайын ба, немесе жауап қайту жолын таба ала ма. Бұл — ядроның маршруттауы мен firewall шешімдері және олар туннельден тыс қабылданады.
Сондықтан сервердің туннель мекенжайына ping жасау соншалықты жаңылыстыратын тест. Ол пакет сервердің өзіне бағытталған, сондықтан ол жергілікті түрде аяқталады. Оған ешқашан жіберу қажет емес, ешқашан аудару қажет емес және ешқашан интернеттен қайтару маршруты қажет емес.
AllowedIPs — маршруттау шешімі
Клиентте AllowedIPs екі жұмыс атқарады. Бұл қандай мақсат мекенжайлары осы серіктестің туннеліне жіберілетінін шешетін криптокілт маршруттау кестесі, және бұл серіктестің сізден қабылдайтын бастау мекенжайларының тізімі. Егер клиент конфигурациясында тек 10.8.0.0/24 көрсетілсе, жария мақсаттар интерфейске ешқашан кірмейді және әдеттегі әдепкі маршрутыңыз оларды туннельден тыс алып кетеді. Сонда туннель мінсіз жұмыс істейді және қалағаныңыздың ешбірін жасамайды.
Конфигурация файлы не дейтініне емес, клиент шын мәнінде нені орнатқанына қараңыз:
wg show wg0 allowed-ipsip route get 1.1.1.1
Екінші команда — шешуші. Егер жауап физикалық интерфейсіңізді және әдеттегі шлюзді атаса, пакет туннель арқылы жүрмейді және сервер жағындағы ешбір өзгеріс оны түзетпейді. IPv4 үшін 0.0.0.0/0, IPv6 үшін ::/0 бөлек қосыңыз; бір отбасы үшін бәрін ұстайтын ереже екіншісін өзінің бастапқы жолында қалдырады, және бұл жұмыс істейтін IPv4 туннелі мен тұрып қалған IPv6 іздеуінің жиі себебі.
Пакет шлюзде қай жерде өледі
Маршрут дұрыс болса да пакет ешқайда бармаса, ол серверге жетіп, сонда тоқтайды. Төрт тексеру шлюздердің көбін қамтиды.
Жіберу. sysctl net.ipv4.ip_forward 0 қайтаруы — классикалық жауап, және көптеген дистрибутивтер әлі де әдепкі бойынша 0-де. Ол 1 болуы керек және оны қайта жүктеуде жоғалатын командамен емес, sysctl файлында тұрақты орнату керек. IPv6 жіберуі бөлек қосқыш.
Сүзгі саясаты. Әдепкі drop саясаты бар FORWARD шынжыры туннель трафигін тастайды, ал хосттың өзіне баратын трафикке рұқсат береді, бұл симптомға дәл сәйкес келеді. Сақталған файлды емес, тірі ережелер жиынтығын оқыңыз: nft list ruleset немесе iptables -S.
Аудару немесе маршруттау. Жеке туннель мекенжайларын пайдаланатын клиенттерге не сервердің шығу интерфейсіндегі бастау NAT, не жоғарғы желі қайтаруды білетін маршрутталған префикс қажет. Екеуінің арасындағы таңдау мекенжай жоспарына сүйенеді. Префиксіңізді қазірдің өзінде кері маршруттайтын желіге MASQUERADE қосу зиянсыз, бірақ пайдасыз, ал маршрут жоқ жерде оны қалдырып кету жауаптарды маршрутталмайтын жеке диапазонға бағытталған күйде қалдырады.
Қайтару жолы. Маршрутталған құрылымдарда жоғарғы роутерге серверіңізді көрсететін маршрут қажет. Провайдер желісі де оны бөгеуі мүмкін: бірнеше бұлт инстанцияда бастау мен мақсатты тексеруді қосады, ол бастауы инстанцияның өз мекенжайы болып табылмайтын пакеттерді сол тексеру өшірілгенше үнсіз тастайды.
DNS маршруттаудан өзгеше сәтсіздікке ұшырайды
Белгілі мекенжайға пакет пен атауды іздеу — екі бөлек ақау, және қате хабарлары қарама-қарсы бағытта жаңылыстырады. Егер ping 1.1.1.1 жұмыс істеп, браузер ештеңе жүктей алмаса, маршрут дұрыс, ал атауларды шешу дұрыс емес. Егер ping өзі сәтсіз болса, DNS маңызсыз және сіз алдыңғы бөлімге оралдыңыз.
wg-quick конфигурациядағы DNS = жолынан resolver орната алады, ал systemd-resolved-тің әр қосылым үшін өз мінез-құлқы бар. Resolver-ді тек туннель ішінде қолжетімді мекенжаймен ауыстыратын VPN туннель құлаған сәтте әр іздеуді сәтсіз етеді, бұл туннель интернетті бұзып жатқандай көрінеді.
| Symptom | Layer to inspect |
|---|---|
| Tunnel address pings, nothing else does | Client route, then gateway forwarding |
| Public IP pings, hostnames fail | Resolver selection and reachability |
| Handshake completes, no reply ever | FORWARD policy or missing NAT on the server |
| Small requests work, large transfers stall | MTU and TCP MSS clamping |
Дәлел беретін рет
Алдымен клиент жағындағы тексеруді орындаңыз, өйткені бұл бір команда және мүмкіндіктердің жартысын жояды. Содан кейін сервердің интернетке шығатын жер ретінде қарастырылғанын растаңыз; жеке қатынас үшін салынған шлюз жария мақсаттар сәтсіз болғанда бұзылған болып саналмайды.
Серверде клиенттен ping жіберіп жатқанда интерфейсті бақылаңыз: tcpdump -ni wg0 icmp сұранысты көрсетуі керек, ал tcpdump -ni eth0 icmp оның шығып бара жатқанын, аударылған немесе аударылмағанын көрсетуі керек. Егер ол біріншісінде көрініп, екіншісінде ешқашан көрінбесе, тоқтау сервердің өзінде. Егер ол шығып, жауап қайтпаса, мәселе жоғарыда, және бұл басқа әңгіме.
Соңында түзету қайта жүктеуден кейін де сақталатынын қамтамасыз етіңіз. Жіберу sysctl файлына, firewall ережелері оларды жүктейтін қызметке, ал клиент маршруттары интерфейсті көтеретін конфигурацияға тиесілі, сіз ұмытып кететін shell-ге емес. Қайта қосылыңыз, сол екі тестті қайталаңыз және санағыштардың қозғалатынын растаңыз.