Csatlakozva az OpenVPN-hez, de semmi sem tölt be: körút a kliens felől kifelé

A kliens ablaka azt írja: Connected, az alagút címe ott van, a böngésző mégis pörög. Ez a kombináció normális, mert a sikeres kézfogás csak azt bizonyítja, hogy az alagút felépült; semmit sem mond arról, hogy a szerver továbbítja-e a csomagjaidat, átírja-e a forrásukat, vagy válaszol-e a DNS-kéréseidre. A legtöbbek hibája, hogy először a szerver konfigurációját nyitják meg. Inkább a kliens felől haladj kifelé, mert az alábbi lépések mindegyike megmondja, hogy a következőt egyáltalán érdemes-e vizsgálni.

Kezdd a kliensnél, és haladj kifelé

Végezz el három tesztet ebben a sorrendben, és írd fel, hol bukik el az első. Pingeld a szerver alagútcímét, ami bizonyítja, hogy maga az alagút szállít forgalmat. Pingelj egy nyilvános címet szám szerint, ami bizonyítja a továbbítást és az átírást névfeloldás nélkül. Utána próbálj feloldani egy hosztnevet, ami az egyetlen teszt, amely a DNS-t használja. Minden eredmény egy egész réteget kivesz a gyanúból.

Ne ugorj a harmadik tesztre csak azért, mert a böngésző gyorsabbnak tűnik. Egy sikertelen oldalbetöltés mindhárom réteget egyszerre fedi le, és éppen onnan indulva kezdik az emberek újraépíteni a működő alagutat. A hibázó oldal nem mondja meg, melyik tört el a háromból.

Két rögzítés megmutatja, hol állnak meg a csomagok

Amíg a klienstől ping fut egy nyilvános címre, készíts egy rögzítést az alagút interfészén, és egyet a felső kapcsolaton, amelynek el kellene érnie az internetet. Futtasd mindkettőt egyszerre, hogy az időbélyegek egyezzenek.

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

Ha a kérések megjelennek az alagúton, és soha a felső kapcsolaton, a szerver eldobta őket az alagút és a kábel között, és az ok a továbbítás vagy a továbbítási tűzfal-szabályzat, nem a NAT. Ha mindkettőn megjelennek, a szerver megtette a magáét, és a válasz hiányzik messzebb, ami az átírásra, egy felső szűrőre vagy a szolgáltató oldali korlátozásra utal.

A felső kapcsolat nevét a routing táblából vedd, ne egy útmutatóból. A felhőképek és az átnevezett adapterek ritkán egyeznek egy útmutató példainterfészével, és a rossz eszközön készült rögzítés pontosan úgy néz ki, mint egy szerver, amely nem továbbít:

ip -4 route get 9.9.9.9

A dev mező abban a kimenetben az a név, amelyre a NAT-szabálynak később szüksége lesz, ezért tartsd meg.

A továbbítás egy kernelkapcsoló és egy tűzfal-szabályzat

A kernelnek egyáltalán hozzá kell járulnia a továbbításhoz. Olvasd ki a jelenlegi értéket, majd tedd tartóssá a beállítást, ahelyett hogy csak a futó kernelbe írnád:

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

A továbbítás csak a fele. Az UFW-t használó hoszton a továbbítási szabályzatot a /etc/default/ufw állítja be, és ACCEPT-nek kell lennie, mielőtt az újratöltés érvénybe lép. A továbbítási útvonalon érvényes alapértelmezett eldobás teljesen egészségesen hagyja a kézfogást, miközben csendben eldob minden csomagot, amely megpróbál kijutni az alagúton, és pontosan ez az a tünet, amivel kezdted.

A nftables-t közvetlenül kezelő hosztok ugyanezzel a kérdéssel szembesülnek más szintaxisban. Figyeld a továbbítási lánc számlálóit, miközben egy klienszteszt fut, mert a lekérdezett lánc és az eldobó lánc ugyanúgy néz ki egy konfigurációs fájlban.

Nevezd meg a valódi kimeneti interfészt a NAT-szabályban

A forrásátírás ahhoz az interfészhez tartozik, amely ténylegesen elhagyja a hosztot, azzal a pool-lal, amelyet a szerver oszt ki. A szabály mindkét felének a valóságot kell leírnia, és egyik sem opcionális.

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

A klasszikus hiba egy útmutatóból másolt szabály, amely azt mondja -o eth0 egy olyan gépen, amelynek adapterét máshogy hívják. A szabály figyelmeztetés nélkül települ, semmire sem illeszkedik, és a kliensnek továbbra sincs internete. A pool ugyanennek a hibának a másik fele: ha a szerver 10.44.0.0/24-et oszt ki, és a szabály 10.8.0.0/24-et fed le, semmi sem fog soha illeszkedni.

Figyeld a számlálókat, ahelyett hogy a szabály szövegében bíznál. A lista szabályonként jelenti a csomagokat, és a soha nem illeszkedő szabály nullán marad, bármilyen helyesnek tűnik is. Adj neki egy perc valódi kliensforgalmat, mielőtt bármit is belemagyaráznál abba a számba:

iptables -t nat -L POSTROUTING -v -n

A nulla csomagszám egy valódi klienszteszt után azt jelenti, hogy az illesztés hibás, nem azt, hogy az alagút elromlott. Amint illeszkedik, mentsd el a szabálykészletet, hogy túléljen egy újraindítást; a javítás, amely csak a shell-előzményeidben él, az első újraindításnál eltűnik.

Ha a szerver felhő-NAT-példány is, a platformnak is van szava. Az a példány, amely címeket ír át, általában a forrás- és célforgalom-ellenőrzést kikapcsolva igényli ott, ahol a szolgáltató ezt a beállítást kínálja, és magának a VPN-portnak kívülről elérhetőnek kell lennie.

A DNS a második hiba az első mögött

Az, hogy cím szerint a ping működik, miközben a nevek elbuknak, feloldóprobléma, és megvan a maga oka. Az a kliens, amely megtartja a helyi feloldóját, ezeket a kéréseket egy teljes alagútba küldi, és olyan válaszra vár, amely soha nem jön meg, mert a helyi feloldó most az útvonal rossz oldalán van.

Küldj feloldót a szerverről, hogy a kliens tudja, hol kérdezzen. Két bejegyzés tartalékot ad a kliensnek, ha az első nem érhető el, és mindkettőnek olyan feloldónak kell lennie, amelyet az alagút ténylegesen enged.

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

A Windows-kliensek aztán mégis visszaeshetnek a helyi feloldóra, és éppen ezt hivatott megakadályozni a block-outside-dns, annak árán, hogy elvesznek azok a nevek, amelyeket csak a helyi hálózat tud feloldni. A systemd-resolvedet használó Linux-kliensek gyakran figyelmen kívül hagyják a küldött feloldót, hacsak egy szkript nem telepíti, ezért ellenőrizd a resolvectl status kimenetét az alagúteszközre, mielőtt arra jutnál, hogy a küldést figyelmen kívül hagyták.

Fejezd be a körutat úgy, ahogy a felhasználó megéli. Tölts be egy valódi oldalt a kliensről, igazold vissza, melyik címről lép ki, indítsd újra a szervert, csatlakozz újra, és ismételd meg a három tesztet. Csak ez a második kör bizonyítja, hogy a mentett szabályok, a tűzfal-szabályzat és a küldött feloldó együtt mind túlélték.