Ferbûn mei OpenVPN, mar neat laden: in rûnlieding fan de klant út

It finster fan de klant seit Connected, it tunneladres is der, en de browser draait noch. Dy kombinaasje is normaal, want in slagge handshake bewiist allinnich dat de tunnel boud is; it seit neat oer de fraach oft de tsjinner jo pakketten trochstjoert, har boarne oerskriuwt of jo DNS-fragen beantwurdet. De flater dy't de measte minsken meitsje is earst de tsjinnerkonfiguraasje iepenje. Wurkje ynstee fan de klant nei bûten, want elke stap hjirûnder seit oft de folgjende it neisjen wol wurdich is.

Begjin by de klant en wurkje nei bûten

Doch trije tests yn dizze folchoarder en skriuw op wêr't de earste misrint. Ping it tunneladres fan de tsjinner, wat bewiist dat de tunnel sels ferkear draacht. Ping in iepenbier adres op nûmer, wat trochstjoeren en oersetting bewiist sûnder nameresolúsje derby te heljen. Probearje dan in hostnamme op te lossen, dat is de iennige test dy't DNS brûkt. Elk resultaat hellet in hiele laach út 'e fertinking.

Spring net nei de tredde test om't in browser flugger fielt. In mislearre sidebelading dekt alle trije lagen tagelyk, en dêr begjinne minsken en bouwe dan in wurkjende tunnel op 'e nij. In side dy't misrint seit net hokker fan 'e trije brutsen is.

Twa opnames litte sjen wêr't de pakketten stopje

Wylst der in ping nei in iepenbier adres fan de klant ôf rint, nim dan ien opname op it tunnelynterface en ien op 'e boppelizzende skeakel dy't it ynternet berikke moat. Lit beide tagelyk rinne sadat de tiidstimpels oerienkomme.

sudo tcpdump -ni tun0 -c 20 icmp
sudo tcpdump -ni enp1s0 -c 20 icmp

As de fersiken op 'e tunnel ferskine en nea op 'e boppelizzende skeakel, hat de tsjinner se tusken de tunnel en de tried falle litten, en de oarsaak is trochstjoeren of it trochstjoerbelied fan 'e firewall, net NAT. As se op beide ferskine, hat de tsjinner syn part dien en mist it antwurd fierder bûten, wat wiist op oersetting, in filter boppe of in beheining fan de provider.

Helle de namme fan 'e boppelizzende skeakel út 'e routetabel, net út in tutorial. Cloud-ôfbyldings en omneamde adapters komme selden oerien mei it foarbyldynterface yn in hantlieding, en in opname op it ferkearde apparaat liket krekt as in tsjinner dy't net trochstjoert:

ip -4 route get 9.9.9.9

It fjild dev yn dy útfier is de namme dy't de NAT-regel letter nedich hat, dus hâld it by.

Trochstjoeren is in kearnskakelaar en in firewallbelied

De kearn moat der hielendal mei ynstimme om troch te stjoeren. Lês de hjoeddeistige wearde en meitsje de ynstelling dan permanint ynstee fan har allinnich yn 'e rinnende kearn te skriuwen:

sysctl net.ipv4.ip_forward
printf 'net.ipv4.ip_forward=1\n' > /etc/sysctl.d/70-vpn-forward.conf
sysctl --system

Trochstjoeren is mar de helte. Op in host mei UFW wurdt it trochstjoerbelied yn /etc/default/ufw set en moat it ACCEPT wêze foardat in werlade effekt hat. In standert drop op it trochstjoerpaad lit de handshake folslein sûn wylst it stilwei elk pakket fuortsmyt dat troch de tunnel nei bûten wol, en dat is krekt it symptoom dêr't jo mei begon binne.

Hosts dy't nftables direkt beheare hawwe deselde fraach yn in oare syntaksis. Sjoch nei de tellers op 'e trochstjoerkeatling wylst in klanttest rint, want in keatling dêr't oan frege wurdt en in keatling dy't fuortsmiten, sjogge der yn in konfiguraasjebestân itselde út.

Nammje it echte útgongsynterface yn 'e NAT-regel

Boarne-oersetting heart op it ynterface dat de host echt ferlit, mei de pool dy't de tsjinner útjout. Beide helten fan dy regel moatte de werklikheid beskriuwe, en gjin fan beide is opsjoneel.

iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o enp1s0 -j MASQUERADE

De klassike mislearring is in regel kopiearre út in hantlieding dy't -o eth0 seit op in masine waans adapter oars hjit. De regel ynstallearret sûnder warskôging, past by neat, en de klant hat noch gjin ynternet. De pool is de oare helte fan deselde flater: as de tsjinner 10.44.0.0/24 útjout en de regel 10.8.0.0/24 dekt, sil neat ea passe.

Sjoch nei de tellers ynstee fan de regeltekst te fertrouwen. De list jout pakketten per regel, en in regel dy't nea past bliuwt op nul, hoe korrekt oft er ek liket. Jou him in minút echt klantferkear foardat jo der wat yn lêze:

iptables -t nat -L POSTROUTING -v -n

Nul pakketten nei in echte klanttest betsjutte dat de oerienkomst ferkeard is, net dat de tunnel brutsen is. Sadree't it past, bewarje de regelset sadat er in werstart oerlibbet; in fix dy't allinnich yn jo shell-skiednis libbet ferdwynt by de earste werstart.

As de tsjinner ek in cloud-NAT-eksimplaar is, hat it platfoarm ek in stim. In eksimplaar dat adressen oerset hat meastentiids de boarne- en bestimmingstsjoch útskeakele nedich wêr't de provider dy ynstelling biedt, en de VPN-poarte sels moat fan bûten berikber wêze.

DNS is de twadde mislearring efter de earste

In ping op adres dat wurket wylst nammen misrinne is in resolverprobleem, en it hat syn eigen oarsaak. In klant dy't syn lokale resolver hâldt stjoert dy fragen in folsleine tunnel yn en wachtet op in antwurd dat nea komt, om't de lokale resolver no oan 'e ferkearde kant fan 'e rûte sit.

Stjoer in resolver fan 'e tsjinner ôf sadat de klant wit wêr't er freegje moat. Twa yngongen jouwe de klant in efterfal as de earste net berikber is, en beide moatte resolvers wêze dy't de tunnel echt tastiet.

push "dhcp-option DNS 9.9.9.9"
push "dhcp-option DNS 149.112.112.112"

Windows-klanten kinne dan dochs weromfalle op 'e lokale resolver, en dat is krekt wat block-outside-dns bestiet om te foarkommen, tsjin de priis fan nammen dy't allinnich it lokale netwurk oplosse kin. Linux-klanten mei systemd-resolved negearje faak in stjoerde resolver útsein as in skript him ynstallearret, dus kontrolearje resolvectl status foar it tunnelapparaat foardat jo konkludearje dat de stjoering negearre is.

Meitsje de rûnlieding dien sa't in brûker it belibbet. Laad in echte side fan de klant, befêstigje it adres dêr't er út wei giet, werstart de tsjinner, ferbyn op 'e nij en werhelje de trije tests. Allinnich dy twadde rûn bewiist dat de bewarre regels, it firewallbelied en de stjoerde resolver allemaal tegearre oerlibbe hawwe.