Ракувањето на WireGuard работи, но нема интернет: следете го пакетот

Тунелот е кренат, wg show пријавува скорешно ракување, можете да пингувате тунелската адреса на серверот и ништо подалеку не одговара. Првиот нагон е да ги регенерирате клучевите или повторно да ја споделите конфигурацијата. Тоа го менува токму оној дел од патеката што веќе е докажано дека работи.

Завршено ракување вели дека двете страни се согласни за клучевите, дека UDP стигнува до крајната точка и дека крипто рутирањето го прифаќа пакетот. Тоа не кажува ништо за тоа дали пакетот потоа може да го напушти серверот.

Затоа следете еден пакет наместо да погодувате. Постојат четири места каде што може да загине, и секое остава различен траг.

Што всушност докажува ракувањето

WireGuard е UDP протокол што воспоставува сесија со Noise ракување и потоа ги шифрира пакетите за партнерот. Кога wg show прикажува ракување старо неколку секунди и растечки бројач на пренос, крајната точка, клучевите и јавниот клуч на партнерот сите се точни.

Она што не го докажува е дека вашиот клиент воопшто испраќа интернетски сообраќај во интерфејсот, дека серверот е подготвен да го проследи или дека одговорот може да го најде патот назад. Тоа се одлуки за рутирање во јадрото и на firewall, и се носат надвор од тунелот.

Затоа пингувањето на тунелската адреса на серверот е толку измамнички тест. Тој пакет е упатен на самиот сервер, па завршува локално. Никогаш не му е потребно проследување, никогаш превод и никогаш повратна рута од интернет.

AllowedIPs е одлука за рутирање

На клиентот AllowedIPs извршува две задачи. Тоа е табелата за криптоклучно рутирање која одлучува кои одредишни адреси се праќаат во тунелот на овој партнер, и тоа е списокот изворни адреси што партнерот ќе ги прифати од вас. Ако конфигурацијата на клиентот наведува само 10.8.0.0/24, јавните одредишта никогаш не влегуваат во интерфејсот и вашата вообичаена стандардна рута ги носи надвор од тунелот. Тогаш тунелот работи совршено и не прави ништо од она што го сакавте.

Погледнете што клиентот навистина инсталирал, а не што вели конфигурациската датотека:

wg show wg0 allowed-ips
ip 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 со адреса достапна само внатре во тунелот ќе го соочи секое пребарување со неуспех во моментот кога тунелот паѓа, што изгледа како тунелот да го крши интернетот.

Ред што дава докази

Прво направете ја проверката на страната на клиентот, зашто тоа е една команда и елиминира половина од можностите. Потоа потврдете дали серверот воопшто е наменет како излез на интернет; порта изградена за приватен пристап не е расипана кога јавните одредишта не работат.

На серверот, набљудувајте го интерфејсот додека праќате ping од клиентот: tcpdump -ni wg0 icmp треба да го покаже барањето, а tcpdump -ni eth0 icmp треба да покаже дека излегува, преведено или не. Ако се појави на првиот и никогаш на вториот, запрењето е локално на серверот. Ако излезе, а одговор не се врати, проблемот е погоре, и тоа е друг разговор.

На крајот, направете поправката да го преживее рестартот. Проследувањето припаѓа во sysctl датотека, правилата на firewall во службата што ги вчитува, а рутите на клиентот во конфигурацијата што го крева интерфејсот, а не во shell што ќе го заборавите. Повторно поврзете се, повторете ги истите два теста и потврдете дека бројачите се движат.