WireGuard-handshake wurket, mar gjin internet: folgje it pakket

De tunnel is oan, wg show meldt in resinte handshake, do kinst de tunneladres fan de tsjinner pingje, en neat fierder antwurdet. De ynstinkt is om kaaien opnij te generearjen of de konfiguraasje opnij te dielen. Dat feroaret krekt it part fan it paad dat al bewiisd is dat it wurket.

In foltôge handshake seit dat de beide pearen it iens binne oer de kaaien, dat UDP it einpunt berikt en dat de kryptorûte it pakket akseptearret. It seit neat oer de fraach oft it pakket dêrnei de tsjinner ferlitte kin.

Folgje dus ien pakket ynstee fan te rieden. Der binne fjouwer plakken dêr’t it stjerre kin, en elk lit in oar spoar efter.

Wat de handshake eins bewiist

WireGuard is in UDP-protokol dat in sesje opset mei in Noise-handshake en dêrnei pakketten fersiferet foar in peer. As wg show in handshake fan in pear sekonden en in stigende oerdrachtsteller lit sjen, binne it einpunt, de kaaien en de iepenbiere kaai fan de peer allegear goed.

Wat it net bewiist, is dat dyn klant internetferkear oerhaads yn ’e ynterface stjoert, dat de tsjinner ree is om it troch te stjoeren, of dat in antwurd de wei werom fine kin. Dat binne besluten fan kernelrûte en firewall, en se wurde bûten de tunnel nommen.

Dêrom is it pingjen fan de tunneladres fan de tsjinner sa’n misliedende test. Dat pakket is rjochte oan de tsjinner sels, dus it einiget lokaal. It hat nea trochstjoeren nedich, nea oersetting en nea in weromrûte fan it internet.

AllowedIPs is in rûtebeslút

Op de klant docht AllowedIPs twa taken. It is de kryptokaai-rûtetabel dy’t beslút hokker bestimmingsadressen yn ’e tunnel fan dizze peer stjoerd wurde, en it is de list mei boarneadressen dy’t de peer fan dy akseptearret. As de konfiguraasje fan de klant allinnich 10.8.0.0/24 neamt, komme iepenbiere bestimmings nea yn ’e ynterface en dyn gewoane standertrûte fiert se bûten de tunnel. Dan wurket de tunnel perfekt en docht er neat fan watsto woe.

Sjoch nei wat de klant eins ynstallearre hat, ynstee fan wat it konfiguraasjebestân seit:

wg show wg0 allowed-ips
ip route get 1.1.1.1

It twadde kommando is it beslissende. As it antwurd dyn fysike ynterface en de gewoane gateway neamt, wurdt it pakket net tunnelle en gjin feroaring oan ’e tsjinnerkant sil dat reparearje. Foegje 0.0.0.0/0 ta foar IPv4 en ::/0 foar IPv6 apart; in regel dy’t alles foar ien famylje pakt, lit de oare op syn oarspronklike paad, en dat is in faak foarkommende oarsaak fan in wurkjende IPv4-tunnel en in fêstrûne IPv6-syktocht.

Wêr’t it pakket op ’e gateway stjert

As de rûte goed is en it pakket giet noch hieltyd nearne hinne, dan komt it by de tsjinner oan en stiet dêr stil. Fjouwer kontrôles dekke de measte gateways.

Trochstjoeren. sysctl net.ipv4.ip_forward dy’t 0 weromjout is it klassike antwurd, en in protte distribúsjes steane noch hieltyd op 0 as standert. It moat 1 wêze, en dat moat permanint yn in sysctl-bestân set wurde ynstee fan mei in kommando dat by in werstart ferdwynt. Trochstjoeren fan IPv6 is in aparte skeakel.

It filterbelied. In FORWARD-keatling mei in standert drop-belied sil tunnelferkear weismite, wylst it ferkear nei de host sels tastean, wat krekt by it symptoom past. Lês de libbene regels, net in bewarre bestân: nft list ruleset of iptables -S.

Oersetting of rûte. Klanten mei privee tunneladressen hawwe of boarne-NAT nedich op ’e útgongsynterface fan de tsjinner, of in rûtearre foarheaksel dat it boppesteande netwurk weromstjoere kin. De kar tusken dy beiden folget it adresplan. MASQUERADE tafoegje oan in netwurk dat dyn foarheaksel al weromrûtet is skealik noch, mar sinleas, en it weilitten dêr’t gjin rûte bestiet lit antwurden adressearre oan in net-rûteber privee berik.

It werompaad. Yn rûtearre ûntwerpen hat de boppesteande router in rûte nedich dy’t nei dyn tsjinner wiist. It netwurk fan de provider kin it ek blokkearje: ferskate clouds sette in boarne- en bestimmingkontrôle oan op ’e instantie, dy’t pakketten stil weismit wêrfan’t de boarne net it eigen adres fan ’e instantie is, oant dy kontrôle útskeakele wurdt.

DNS falt oars as rûte

In pakket nei in bekend adres en in namsyktocht binne twa ferskillende flaters, en de flaterberjochten misliede yn tsjinstelde rjochtingen. As ping 1.1.1.1 wurket en in browser kin neat lade, dan is de rûte goed en de namresolúsje net. As de ping sels falt, is DNS net fan belang en bist werom by de foarige seksje.

wg-quick kin in resolver sette út ’e rigel DNS = yn ’e konfiguraasje, en systemd-resolved hat syn eigen gedrach per keppeling. In VPN dy’t de resolver oerskriuwt mei in adres dat allinnich yn ’e tunnel berikber is, sil elke syktocht misse op it momint dat de tunnel falt, wat liket as brekt de tunnel it internet.

In folchoarder dy’t bewiis leveret

Doch earst de kontrôle oan ’e klantkant, want it is ien kommando en it skrast de helte fan ’e mooglikheden út. Befêstigje dan oft de tsjinner oerhaads bedoeld is as internetútgong; in gateway boud foar privee tagong is net stikken as iepenbiere bestimmings misse.

Op ’e tsjinner, sjoch nei de ynterface wylst do in ping fan ’e klant stjoerst: tcpdump -ni wg0 icmp heart it fersyk te sjen te jaan, en tcpdump -ni eth0 icmp heart te sjen te jaan dat it fuortgiet, oerset of net. As it op ’e earste ferskynt en nea op ’e twadde, dan is it stopjen lokaal op ’e tsjinner. As it fuortgiet en der komt gjin antwurd werom, dan is it probleem boppe en dat is in oar petear.

Meitsje ta beslút dat de repaasje in werstart oerlibbet. Trochstjoeren heart yn in sysctl-bestân, firewallregels hearre yn ’e tsjinst dy’t se laadt, en klantrûtes hearre yn ’e konfiguraasje dy’t de ynterface omheech bringt, net yn in shell dy’tst ferjitte silst. Ferbyn op ’e nij, werhelje deselde twa tests en befêstigje dat de tellers bewege.