WireGuard-handskud werk, maar geen internet: volg die pakket

Die tonnel is op, wg show rapporteer ’n onlangse handskud, jy kan die bediener se tonneladres ping, en niks verder antwoord nie. Die instink is om sleutels te hergenereer of die konfigurasie weer te deel. Dit verander juis die een deel van die pad wat reeds bewys is dat dit werk.

’n Voltooide handskud sê die twee eweknieë stem oor sleutels saam, dat UDP die eindpunt bereik, en dat die kriptoroetering die pakket aanvaar. Dit sê niks oor of die pakket daarna die bediener kan verlaat nie.

Volg dus een pakket in plaas van om te raai. Daar is vier plekke waar dit kan sterf, en elkeen laat ’n ander spoor.

Wat die handskud werklik bewys

WireGuard is ’n UDP-protokol wat ’n sessie met ’n Noise-handskud vestig en dan pakkette vir ’n eweknie versleutel. Wanneer wg show ’n handskud van ’n paar sekondes oud en ’n stygende oordragteller lys, is die eindpunt, die sleutels en die eweknie se publieke sleutel almal korrek.

Wat dit nie bewys nie, is dat jou kliënt internetgerigte verkeer hoegenaamd in die koppelvlak stuur, dat die bediener gewillig is om dit aan te stuur, of dat ’n antwoord sy weg terug kan vind. Dit is kernelroetering- en firewall-besluite, en hulle word buite die tonnel geneem.

Daarom is dit so ’n misleidende toets om die bediener se tonneladres te ping. Daardie pakket is aan die bediener self gerig, so dit eindig plaaslik. Dit het nooit aansturing nodig nie, nooit vertaling nie, en nooit ’n terugroete van die internet nie.

AllowedIPs is ’n roeteringsbesluit

Op die kliënt doen AllowedIPs twee take. Dit is die kriptosleutel-roetertabel wat besluit watter bestemmingsadresse in hierdie eweknie se tonnel gestuur word, en dit is die lys bronadresse wat die eweknie van jou sal aanvaar. As die kliënt se konfigurasie net 10.8.0.0/24 lys, kom publieke bestemmings nooit in die koppelvlak nie en jou gewone verstekroete dra hulle buite die tonnel. Die tonnel werk dan perfek en doen niks wat jy wou hê nie.

Kyk na wat die kliënt werklik geïnstalleer het eerder as wat die konfigurasielêer sê:

wg show wg0 allowed-ips
ip route get 1.1.1.1

Die tweede opdrag is die deurslaggewende een. As die antwoord jou fisiese koppelvlak en die gewone poort noem, word die pakket nie deur die tonnel gestuur nie en geen verandering aan die bedienerkant sal dit regstel nie. Voeg 0.0.0.0/0 vir IPv4 en ::/0 vir IPv6 afsonderlik by; ’n vangnet vir een familie laat die ander op sy oorspronklike pad, wat ’n algemene oorsaak is van ’n werkende IPv4-tonnel en ’n stilstaande IPv6-soektog.

Waar die pakket by die poort sterf

As die roete korrek is en die pakket gaan steeds nêrens heen nie, kom dit by die bediener aan en stop daar. Vier kontroles dek die meeste poorte.

Aansturing. sysctl net.ipv4.ip_forward wat 0 teruggee is die klassieke antwoord, en baie verspreidings is steeds by verstek op 0. Dit moet 1 wees, en aanhoudend ingestel in ’n sysctl-drop-in eerder as met ’n opdrag wat by herlaai verdwyn. IPv6-aansturing is ’n aparte skakelaar.

Die filterbeleid. ’n FORWARD-ketting met ’n verstek-verwerpbeleid sal tonnelverkeer weggooi terwyl dit verkeer na die gasheer self toelaat, wat presies by die simptoom pas. Lees die lewendige reëlstel, nie ’n gestoorde lêer nie: nft list ruleset of iptables -S.

Vertaling of roetering. Kliënte wat private tonneladresse gebruik, het óf bron-NAT op die bediener se uitgangskoppelvlak nodig óf ’n geroteerde voorvoegsel wat die opstroomnetwerk weet hoe om terug te stuur. Die keuse tussen hulle volg die adresplan. Om MASQUERADE by te voeg by ’n netwerk wat jou voorvoegsel reeds terugroeteer, is onskadelik maar sinneloos, en om dit weg te laat waar geen roete bestaan nie, laat antwoorde gerig aan ’n onroeteerbare private reeks.

Die terugpad. In geroteerde ontwerpe het die opstroomroeteerder ’n roete nodig wat na jou bediener wys. Die verskaffer se netwerk kan dit ook blokkeer: verskeie wolke aktiveer ’n bron- en bestemmingskontrole op die instansie, wat pakkette stilweg laat val waarvan die bron nie die instansie se eie adres is nie, totdat daardie kontrole gedeaktiveer word.

DNS faal anders as roetering

’n Pakket na ’n bekende adres en ’n naamsoektog is aparte foute, en die foutboodskappe mislei in teenoorgestelde rigtings. As ping 1.1.1.1 werk en ’n blaaier kan niks laai nie, is die roete reg en die naamresolusie nie. As die ping self misluk, is DNS irrelevant en is jy terug by die vorige afdeling.

wg-quick kan ’n oplosser stel vanaf die DNS =-reël in die konfigurasie, en systemd-resolved het sy eie gedrag per skakel. ’n VPN wat die oplosser oorskryf met ’n adres wat net binne die tonnel bereikbaar is, sal elke soektog laat misluk sodra die tonnel val, wat lyk asof die tonnel die internet breek.

Orde wat bewyse lewer

Begin met die kontrole aan die kliëntkant, want dit is een opdrag en dit skakel die helfte van die moontlikhede uit. Bevestig dan of die bediener hoegenaamd as ’n internetuitgang bedoel is; ’n poort wat vir private toegang gebou is, is nie stukkend wanneer publieke bestemmings misluk nie.

Op die bediener, kyk na die koppelvlak terwyl jy ’n ping van die kliënt stuur: tcpdump -ni wg0 icmp behoort die versoek te wys, en tcpdump -ni eth0 icmp behoort dit te wys terwyl dit vertrek, vertaal of nie. As dit op die eerste verskyn en nooit op die tweede nie, is die stop plaaslik by die bediener. As dit vertrek en geen antwoord kom terug nie, is die probleem opstroom, en dit is ’n ander gesprek.

Maak laastens dat die regstelling ’n herlaai oorleef. Aansturing hoort in ’n sysctl-lêer, firewall-reëls hoort in die diens wat hulle laai, en kliëntroetes hoort in die konfigurasie wat die koppelvlak opbring eerder as in ’n dop wat jy sal vergeet. Herverbind, herhaal dieselfde twee toetse en bevestig dat die tellers beweeg.