Aan OpenVPN gekoppel, maar niks laai nie: 'n deurloop vir die kliënt

Die kliëntvenster sê Connected, die tonneladres is daar, en die blaaier draai steeds. Daardie kombinasie is normaal, want 'n suksesvolle handdruk bewys net dat die tonnel gebou is; dit sê niks oor of die bediener jou pakkette sal aanstuur, hul bron sal herskryf, of jou DNS-navrae sal beantwoord nie. Die fout wat die meeste mense maak, is om eerste die bedienerkonfigurasie oop te maak. Werk eerder van die kliënt af na buite, want elke stap hieronder sê vir jou of die volgende een selfs die moeite werd is om na te gaan.

Begin by die kliënt en werk na buite

Voer drie toetse in hierdie volgorde uit en skryf neer waar die eerste een misluk. Ping die bediener se tonneladres, wat bewys dat die tonnel self verkeer dra. Ping 'n openbare adres per nommer, wat aanstuur en vertaling bewys sonder om naamresolusie te betrek. Probeer dan 'n hostnaam oplos, wat die enigste toets is wat DNS gebruik. Elke resultaat verwyder 'n hele laag uit vermoede.

Moenie na die derde toets oorslaan net omdat 'n blaaier vinniger voel nie. 'n Mislukte bladsy-laai dek al drie lae gelyk, en dit is waar mense begin en dan 'n werkende tonnel herbou. 'n Mislukte bladsy sê niks oor watter van die drie gebreek het nie.

Twee opnames wys waar die pakkette stop

Met 'n ping na 'n openbare adres wat vanaf die kliënt loop, neem een opname op die tonnelkoppelvlak en een op die opdraende skakel wat veronderstel is om die internet te bereik. Hardloop albei op dieselfde tyd sodat die tydstempels ooreenstem.

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

As die versoeke op die tonnel verskyn en nooit op die opdraende skakel nie, het die bediener hulle tussen die tonnel en die draad laat val, en die oorsaak is aanstuur of die aanstuur-brandmuurbeleid, nie NAT nie. As hulle op albei verskyn, het die bediener sy deel gedoen en die antwoord ontbreek verder uit, wat op vertaling, 'n stroomop-filter of 'n beperking van die verskaffer dui.

Kry die opdraende skakel se naam uit die roetetabel, nie uit 'n handleiding nie. Wolkbeelde en hernoemde adapters pas selde by die voorbeeldkoppelvlak in 'n gids, en 'n opname wat op die verkeerde toestel geneem is, lyk presies soos 'n bediener wat nie aanstuur nie:

ip -4 route get 9.9.9.9

Die dev-veld in daardie uitset is die naam wat die NAT-reël later nodig het, so hou dit.

Aanstuur is 'n kernskakelaar en 'n brandmuurbeleid

Die kern moet heel eerste instem om aan te stuur. Lees die huidige waarde, en maak die instelling dan permanent in plaas daarvan om dit net in die lopende kern te skryf:

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

Aanstuur is net die helfte daarvan. Op 'n gasheer met UFW word die aanstuurbeleid in /etc/default/ufw gestel en moet dit ACCEPT wees voordat 'n herlaai effek het. 'n Verstek-verwerping op die aanstuurpad laat die handdruk heeltemal gesond, terwyl elke pakket wat deur die tonnel wil uitgaan, stilweg weggegooi word — presies die simptoom waarmee jy begin het.

Gashere wat nftables direk bestuur, het dieselfde vraag in 'n ander sintaksis. Kyk na die tellers op die aanstuurketting terwyl 'n kliënttoets loop, want 'n ketting wat geraadpleeg word en een wat wegwerp, lyk in 'n konfigurasielêer identies.

Noem die werklike uitgangskoppelvlak in die NAT-reël

Bronvertaling hoort op die koppelvlak wat werklik die gasheer verlaat, met die poel wat die bediener uitdeel. Albei helftes van daardie reël moet die werklikheid beskryf, en nie een is opsioneel nie.

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

Die klassieke fout is 'n reël wat uit 'n gids gekopieer is en -o eth0 sê op 'n masjien wie se adapter anders heet. Die reël installeer sonder 'n waarskuwing, pas by niks, en die kliënt het steeds geen internet nie. Die poel is die ander helfte van dieselfde fout: as die bediener 10.44.0.0/24 stoot en die reël 10.8.0.0/24 dek, sal niks ooit pas nie.

Kyk na die tellers eerder as om die reëlteks te vertrou. Die lys gee pakkette per reël, en 'n reël wat nooit pas nie, bly op nul hoe korrek dit ook lyk. Gee dit 'n minuut se werklike kliëntverkeer voordat jy enigiets uit daardie getal aflei:

iptables -t nat -L POSTROUTING -v -n

Nul pakkette ná 'n werklike kliënttoets beteken die passing is verkeerd, nie dat die tonnel gebreek is nie. Sodra dit pas, stoor die reëlstel sodat dit 'n herbegin oorleef; 'n oplossing wat net in jou shell-geskiedenis leef, verdwyn by die eerste herbegin.

As die bediener ook 'n wolk-NAT-instansie is, het die platform 'n sê. 'n Instansie wat adresse vertaal, het gewoonlik sy bron- en bestemmingskontrole gedeaktiveer nodig waar die verskaffer daardie instelling bied, en die VPN-poort self moet van buite bereikbaar wees.

DNS is die tweede fout agter die eerste

Ping per adres wat werk terwyl name misluk, is 'n oplosserprobleem, en dit het sy eie oorsaak. 'n Kliënt wat sy plaaslike oplosser hou, stuur daardie navrae in 'n volle tonnel in en wag vir 'n antwoord wat nooit kom nie, want die plaaslike oplosser is nou aan die verkeerde kant van die roete.

Stoot 'n oplosser van die bediener af sodat die kliënt weet waar om te vra. Twee inskrywings gee die kliënt 'n terugval as die eerste onbereikbaar is, en albei moet oplossers wees wat die tonnel werklik toelaat.

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

Windows-kliënte val dan dalk steeds terug op die plaaslike oplosser, en dit is wat block-outside-dns bestaan om te voorkom, ten koste van name wat net die plaaslike netwerk kan oplos. Linux-kliënte met systemd-resolved ignoreer dikwels 'n gestootde oplosser tensy 'n script dit installeer, so kyk na resolvectl status vir die tonneltoestel voordat jy aflei dat die stoot geïgnoreer is.

Voltooi die deurloop soos 'n gebruiker dit ervaar. Laai 'n werklike bladsy vanaf die kliënt, bevestig die adres waar dit uitgaan, herbegin die bediener, koppel weer, en herhaal die drie toetse. Daardie tweede ronde is die enigste een wat bewys dat die gestoorde reëls, die brandmuurbeleid en die gestootde oplosser saam oorleef het.