Руковање WireGuard-а ради, али нема интернета: пратите пакет
Руковање доказује само кључеве и доступност. Пратите један пакет од AllowedIPs кроз прослеђивање, NAT и повратну руту да видите где се зауставља.
Тунел је подигнут, wg show пријављује недавно руковање, можете да пингујете тунелску адресу сервера, а ништа иза ње не одговара. Први нагон је да поново генеришете кључеве или поново поделите конфигурацију. То мења управо онај део пута за који је већ доказано да ради.
Завршено руковање каже да су две стране сагласне око кључева, да UDP стиже до крајње тачке и да крипто рутирање прихвата пакет. Не каже ништа о томе може ли пакет затим да напусти сервер.
Зато пратите један пакет уместо да нагађате. Постоје четири места на којима може да погине, и свако оставља другачији траг.
Шта руковање заправо доказује
WireGuard је UDP протокол који успоставља сесију Noise руковањем и затим шифрује пакете за партнера. Када wg show прикаже руковање старо неколико секунди и растући бројач преноса, крајња тачка, кључеви и јавни кључ партнера су сви тачни.
Оно што не доказује јесте да ваш клијент уопште шаље интернетски саобраћај у интерфејс, да је сервер вољан да га проследи или да одговор може да нађе пут назад. То су одлуке рутирања у језгру и на заштитном зиду, и доносе се изван тунела.
Зато је пинг на тунелску адресу сервера тако обмањујући тест. Тај пакет је упућен самом серверу, па се завршава локално. Никада му не треба прослеђивање, никада превод и никада повратна рута са интернета.
AllowedIPs је одлука о рутирању
На клијенту AllowedIPs обавља два посла. То је табела криптокључног рутирања која одлучује које одредишне адресе иду у тунел овог партнера, и то је списак изворних адреса које ће партнер прихватити од вас. Ако конфигурација клијента наводи само 10.8.0.0/24, јавна одредишта никада не улазе у интерфејс и ваша уобичајена подразумевана рута их носи изван тунела. Тада тунел ради савршено и не чини ништа од онога што сте желели.
Погледајте шта је клијент заиста инсталирао, а не шта каже конфигурациона датотека:
wg show wg0 allowed-ipsip route get 1.1.1.1
Друга команда је пресудна. Ако одговор наводи ваш физички интерфејс и уобичајену капију, пакет се не тунелира и никаква промена на страни сервера то неће поправити. Додајте 0.0.0.0/0 за IPv4 и ::/0 за IPv6 одвојено; правило које хвата све за једну фамилију оставља другу на њеној изворној путањи, и то је чест узрок тунела IPv4 који ради и заглављеног IPv6 претраживања.
Где пакет умире на капији
Ако је рута тачна, а пакет и даље не иде никуда, он стиже на сервер и тамо се зауставља. Четири провере покривају већину капија.
Прослеђивање. sysctl net.ipv4.ip_forward који враћа 0 је класичан одговор, и многе дистрибуције су и даље подразумевано на 0. Мора да буде 1, и то трајно постављено у sysctl датотеци, а не командом која нестаје при рестарту. Прослеђивање IPv6 је одвојен прекидач.
Политика филтрирања. Ланац FORWARD са подразумеваном политиком одбацивања одбациваће тунелски саобраћај, а пропуштати саобраћај ка самом домаћину, што се тачно поклапа са симптомом. Читајте живи скуп правила, а не сачувану датотеку: nft list ruleset или iptables -S.
Превод или рутирање. Клијентима са приватним тунелским адресама потребан је или изворни NAT на излазном интерфејсу сервера, или рутирани префикс који горња мрежа зна да врати. Избор између њих следи план адреса. Додавање MASQUERADE мрежи која већ рутира ваш префикс назад је безопасно, али бесмислено, а његово изостављање тамо где рута не постоји оставља одговоре упућене на нерутирајући приватни опсег.
Повратна путања. У рутираним дизајни��а горњем рутеру је потребна рута која показује на ваш сервер. Мрежа провајдера то такође може да блокира: неколико облака укључује проверу извора и одредишта на инстанци, која тихо одбацује пакете чији извор није сопствена адреса инстанце, док се та провера не искључи.
DNS отказује другачије од рутирања
Пакет до познате адресе и претрага имена су два одвојена квара, и поруке о грешци обмањују у супротним смеровима. Ако ping 1.1.1.1 ради, а прегледач не може ништа да учита, рута је у реду, а резолуција имена није. Ако сам ping не успе, DNS је неважан и вратили сте се на претходни одељак.
wg-quick може да постави resolver из линије DNS = у конфигурацији, а systemd-resolved има своје понашање по вези. VPN који препише resolver адресом доступном само унутар тунела осудиће сваку претрагу на неуспех у тренутку када тунел падне, што изгледа као да тунел квари интернет.
| 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 датотеци, правила заштитног зида припадају сервису који их учитава, а руте клијента припадају конфигурацији која подиже интерфејс, а не shell-у који ћете заборавити. Поново се повежите, поновите иста два теста и потврдите да се бројачи померају.