Konektita al OpenVPN sed nenio ŝargiĝas: promeno de la kliento eksteren

La klienta fenestro diras Connected, la tunela adreso ĉeestas, kaj la retumilo ankoraŭ turniĝas. Tiu kombino estas normala, ĉar sukcesa manpremo pruvas nur, ke la tunelo estis konstruita; ĝi diras nenion pri tio, ĉu la servilo plusendos viajn pakaĵojn, reskribos ilian fonton aŭ respondos viajn DNS-demandojn. La eraro, kiun plej multaj faras, estas malfermi unue la servilan agordon. Laboru anstataŭe de la kliento eksteren, ĉar ĉiu paŝo sube diras al vi, ĉu la sekva eĉ indas kontrolon.

Komencu ĉe la kliento kaj laboru eksteren

Faru tri testojn en tiu ordo kaj notu, kie la unua malsukcesas. Pingu la tunelan adreson de la servilo, kio pruvas, ke la tunelo mem portas trafikon. Pingu publikan adreson laŭ nombro, kio pruvas plusendadon kaj tradukadon sen impliki nomrezolucion. Poste provu rezolvi gastigantan nomon, kio estas la sola testo, kiu uzas DNS. Ĉiu rezulto forigas tutan tavolon el suspekto.

Ne saltu al la tria testo ĉar retumilo ŝajnas pli rapida. Malsukcesa paĝoŝarĝo kovras ĉiujn tri tavolojn samtempe, kaj ĝuste tie homoj komencas kaj poste rekonstruas tunelon, kiu funkciis. Malsukcesa paĝo diras al vi nenion pri tio, kiu el la tri rompiĝis.

Du kaptoj montras, kie la pakaĵoj haltas

Dum ping al publika adreso kuras de la kliento, prenu unu kapton sur la tunela interfaco kaj unu sur la suprena ligilo, kiu devus atingi la interreton. Rulu ambaŭ samtempe, por ke la tempomarkoj kongruu.

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

Se la petoj aperas sur la tunelo kaj neniam sur la suprena ligilo, la servilo forĵetis ilin inter la tunelo kaj la kablo, kaj la kaŭzo estas plusendado aŭ la plusenda fajroŝirma politiko, ne NAT. Se ili aperas sur ambaŭ, la servilo faris sian parton kaj la respondo mankas pli ekstere, kio montras al tradukado, supra filtrilo aŭ limigo de la provizanto.

Prenu la nomon de la suprena ligilo el la enkursiga tabelo, ne el lernilo. Nubaj bildoj kaj renomitaj adaptiloj malofte kongruas kun la ekzempla interfaco en gvidilo, kaj kapto farita sur la malĝusta aparato aspektas ĝuste kiel servilo, kiu ne plusendas:

ip -4 route get 9.9.9.9

La kampo dev en tiu eligo estas la nomo, kiun la NAT-regulo bezonos poste, do konservu ĝin.

Plusendado estas kernŝaltilo kaj fajroŝirma politiko

La kerno devas konsenti plusendi entute. Legu la nunan valoron, poste faru la agordon permanenta anstataŭ skribi ĝin nur en la kurantan kernon:

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

Plusendado estas nur duono. En gastiganto uzanta UFW la plusenda politiko estas agordata en /etc/default/ufw kaj devas esti ACCEPT antaŭ ol reŝargo efikas. Defaŭlta forĵeto sur la plusenda vojo lasas la manpremon tute sana, dum ĝi silenteme forĵetas ĉiun pakaĵon, kiu provas eliri tra la tunelo, kio estas ĝuste la simptomo, per kiu vi komencis.

Gastigantoj, kiuj administras nftables rekte, havas la saman demandon en alia sintakso. Rigardu la nombrilojn sur la plusenda ĉeno dum klienta testo kuras, ĉar ĉeno konsultata kaj ĉeno forĵetanta aspektas idente en agorda dosiero.

Nomu la veran eliran interfacon en la NAT-regulo

Fonta tradukado apartenas al la interfaco, kiu vere forlasas la gastiganton, kun la baseno, kiun la servilo disdonas. Ambaŭ duonoj de tiu regulo devas priskribi la realon, kaj neniu estas laŭvola.

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

La klasika malsukceso estas regulo kopiita el gvidilo, kiu diras -o eth0 sur maŝino, kies adaptilo nomiĝas alie. La regulo instaliĝas sen averto, kongruas kun nenio, kaj la kliento ankoraŭ ne havas interreton. La baseno estas la alia duono de la sama eraro: se la servilo disdonas 10.44.0.0/24 kaj la regulo kovras 10.8.0.0/24, nenio iam kongruos.

Rigardu la nombrilojn anstataŭ fidi la regulan tekston. La listo raportas pakaĵojn po regulo, kaj regulo, kiu neniam kongruas, restas ĉe nulo, kiel ajn ĝusta ĝi aspektas. Donu al ĝi unu minuton da vera klienta trafiko antaŭ ol legi ion en tiun nombron:

iptables -t nat -L POSTROUTING -v -n

Nula pakaĵnombro post vera klienta testo signifas, ke la kongruo estas malĝusta, ne ke la tunelo rompiĝis. Post kiam ĝi kongruas, konservu la regulan aron, por ke ĝi postvivu restartigon; ripeto, kiu vivas nur en via ŝela historio, malaperas ĉe la unua restartigo.

Se la servilo estas ankaŭ nuba NAT-kopio, la platformo ankaŭ havas voĉon. Kopio, kiu tradukas adresojn, kutime bezonas malŝaltitan fontan kaj celan kontrolon tie, kie la provizanto proponas tiun agordon, kaj la VPN-pordo mem devas esti atingebla de ekstere.

DNS estas la dua malsukceso malantaŭ la unua

Ping laŭ adreso funkcianta dum nomoj malsukcesas estas rezolvilproblemo, kaj ĝi havas sian propran kaŭzon. Kliento, kiu tenas sian lokan rezolvilon, sendas tiujn demandojn en plenan tunelon kaj atendas respondon, kiu neniam venas, ĉar la loka rezolvilo nun estas sur la malĝusta flanko de la enkursigo.

Puŝu rezolvilon de la servilo, por ke la kliento sciu, kie demandi. Du enskriboj donas al la kliento rezervan eblon, se la unua neatingeblas, kaj ambaŭ devus esti rezolviloj, kiujn la tunelo vere permesas.

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

Windows-klientoj tiam eble tamen reiros al la loka rezolvilo, kaj ĝuste tion block-outside-dns ekzistas por malhelpi, je la kosto perdi nomojn, kiujn nur la loka reto povas rezolvi. Linux-klientoj kun systemd-resolved ofte ignoras puŝitan rezolvilon, se skripto ne instalas ĝin, do kontrolu resolvectl status por la tunela aparato antaŭ ol konkludi, ke la puŝo estis ignorita.

Finu la promenon tiel, kiel uzanto spertas ĝin. Ŝargu veran paĝon de la kliento, konfirmu la adreson, de kiu ĝi eliras, restartigu la servilon, rekonektiĝu kaj ripetu la tri testojn. Nur tiu dua pasado pruvas, ke la konservitaj reguloj, la fajroŝirma politiko kaj la puŝita rezolvilo ĉiuj kune postvivis.