Tengdur við OpenVPN en ekkert hleðst: ganga frá biðlaranum og út

Gluggi biðlarans segir Connected, gangaheimilið er þar, og vafrinn snýst enn. Þessi samsetning er eðlileg, því tókst handaband sannar aðeins að göngin hafi verið byggð; það segir ekkert um hvort þjónninn muni senda pakkana þína áfram, endurskrifa uppruna þeirra eða svara DNS-fyrirspurnum þínum. Mistakið sem flestir gera er að opna stillingar þjónsins fyrst. Vinnaðu í staðinn frá biðlaranum og út, því hvert skref hér að neðan segir þér hvort næsta skrefið sé jafnvel þess virði að skoða.

Byrjaðu á biðlaranum og vinnaðu út

Gerðu þrjár prófanir í þessari röð og skrifaðu niður hvar sú fyrsta mistekst. Pingaðu gangaheimilið á þjóninum, sem sannar að göngin sjálf flytja umferð. Pingaðu opinbert heimilisfang eftir númeri, sem sannar áframflutning og þýðingu án þess að nafnaleysing komi við sögu. Reyndu svo að leysa hýsilnafn, sem er eina prófunin sem notar DNS. Sérhver niðurstaða fjarlægir heila lag frá grunsemdum.

Ekki hoppa í þriðju prófunina af því að vafrinn virðist hraðari. Misheppnuð hleðsla síðu nær yfir öll þrjú lögin í einu, og þaðan byrja menn og endurbyggja svo göng sem virkuðu. Síða sem mistekst segir þér ekki hvaða lag af þremur brotnaði.

Tvær upptökur sýna hvar pakkarnir stöðvast

Meðan ping á opinbert heimilisfang gengur frá biðlaranum skaltu taka eina upptöku á gangatengingunni og aðra á uppstreymisstrengnum sem á að ná til internetsins. Láttu báðar ganga samtímis svo tímasetningarnar passi saman.

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

Ef beiðnirnar birtast á göngunum og aldrei á uppstreymisstrengnum hefur þjónninn hent þeim milli ganganna og vírsins, og orsökin er áframflutningur eða eldveggsstefna áframflutnings, ekki NAT. Ef þær birtast á báðum hefur þjónninn gert sitt og svarið vantar lengra út, sem bendir til þýðingar, síu ofar eða takmörkunar frá veitandanum.

Fáðu nafn uppstreymisstrengsins úr leiðarvísitöflunni, ekki úr kennsluefni. Skýjaflutningar og endurnefndar millistykki passa sjaldan við dæmatengingu leiðarvísis, og upptaka á röngu tæki lítur nákvæmlega út eins og þjónn sem flytur ekki áfram:

ip -4 route get 9.9.9.9

Reiturinn dev í þeirri útkomu er nafnið sem NAT-reglan þarf síðar, svo haltu því.

Áframflutningur er kjarnarofi og eldveggsstefna

Kjarninn verður að samþykkja áframflutning yfirhöfuð. Lestu núgildandi gildi og gerðu stillinguna síðan varanlega í stað þess að skrifa hana bara í kjarnann sem er í gangi:

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

Áframflutningur er aðeins helmingurinn. Á hýsli með UFW er stefnan fyrir áframflutning stillt í /etc/default/ufw og verður að vera ACCEPT áður en endurhleðsla tekur gildi. Sjálfgefin höfnun á áframflutningsleiðinni lætur handabandið vera fullkomlega heilbrigt en hendir hljóðlaust hverjum pakka sem reynir að komast út um göngin, og það er nákvæmlega einkennið sem þú byrjaðir með.

Hýslar sem stjórna nftables beint standa frammi fyrir sömu spurningu í annarri setningagerð. Fylgstu með teljunum á áframflutningskeðjunni meðan prófun biðlarans gengur, því keðja sem er spurð og keðja sem hendir líta eins út í stillingaskrá.

Nefndu raunverulegu útgangstenginguna í NAT-reglunni

Upprununarþýðing á heima á tengingunni sem raunverulega yfirgefur hýsilinn, með því safni sem þjónninn úthlutar. Báðir helmingar þeirrar reglu verða að lýsa raunveruleikanum, og hvorugur er valkvæður.

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

Klassíska mistakið er regla sem er afrituð úr leiðarvísi sem segir -o eth0 á vél þar sem millistykkið heitir eitthvað annað. Reglan setjist upp án viðvörunar, passar við ekkert, og biðlarinn hefur enn ekkert internet. Safnið er hinn helmingurinn af sömu mistökum: ef þjónninn úthlutar 10.44.0.0/24 og reglan nær yfir 10.8.0.0/24 mun ekkert nokkurn tíma passa.

Fylgstu með teljunum í stað þess að treysta texta reglunnar. Listinn greinir frá pökkum á hverja reglu, og regla sem passar aldrei verður áfram á núlli hversu rétt sem hún lítur út. Gefðu henni eina mínútu af raunverulegri umferð biðlarans áður en þú lest nokkuð út úr þeirri tölu:

iptables -t nat -L POSTROUTING -v -n

Núll pakkatala eftir raunverulega prófun biðlarans þýðir að samsvörunin er röng, ekki að göngin séu brotin. Þegar hún passar skaltu vista reglusafnið svo það lifi endurræsingu; viðgerð sem lifir aðeins í skeljasögu þinni hverfur við fyrstu endurræsingu.

Ef þjónninn er líka skýja-NAT-tilvik hefur vettvangurinn líka eitthvað að segja. Tilvik sem þýðir heimilisföng þarf venjulega að hafa uppruna- og áfangaprófun óvirka þar sem veitandinn býður þá stillingu, og VPN-portið sjálft verður að vera aðgengilegt utan frá.

DNS er önnur mistökin á bak við þau fyrstu

Að pinga eftir heimilisfangi virki meðan nöfn mistekst er vandamál leysisins, og það á sér sína orsök. Biðlari sem heldur sínum staðbundna leysi sendir þessar fyrirspurnir inn í full göng og bíður svars sem kemur aldrei, því staðbundni leysirinn er núna hinum megin við leiðina.

Ýttu leysi frá þjóninum svo biðlarinn viti hvar hann á að spyrja. Tvær færslur gefa biðlaranum varavalskost ef fyrsta er óaðgengileg, og báðar ættu að vera leysar sem göngin leyfa raunverulega.

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

Windows-biðlarar geta svo samt fallið til baka á staðbundna leysinn, og það er einmitt það sem block-outside-dns er til að koma í veg fyrir, á kostnað þess að nöfn sem aðeins staðbundna netið getur leyst tapist. Linux-biðlarar með systemd-resolved hunsa oft ýttan leysi nema skriftu setji hann upp, svo athugaðu resolvectl status fyrir gangatækið áður en þú ályktar að ýtingunni hafi verið hunsuð.

Kláraðu gönguna eins og notandi upplifir hana. Hlaða raunverulegri síðu frá biðlaranum, staðfestu heimilisfangið sem hún fer út frá, endurræstu þjóninn, tengdu aftur og endurtaktu þrjár prófanir. Aðeins þessi seinni umferð sannar að vistuðu reglurnar, eldveggsstefnan og ýtti leysirinn hafi allt lifað saman.