Prisijungta prie OpenVPN, bet nieko neįkelia: ėjimas nuo kliento į išorę

Kliento lange rašoma Connected, tunelio adresas yra, o naršyklė vis dar sukasi. Toks derinys normalus, nes sėkmingas rankos paspaudimas įrodo tik tai, kad tunelis buvo pastatytas; jis nieko nesako apie tai, ar serveris persiųs jūsų paketus, perrašys jų šaltinį ar atsakys į jūsų DNS užklausas. Daugumos klaida – pirmiausia atidaryti serverio konfigūraciją. Vietoj to eikite nuo kliento į išorę, nes kiekvienas žingsnis žemiau pasako, ar kitą verta tikrinti.

Pradėkite nuo kliento ir eikite į išorę

Atlikite tris testus šia tvarka ir užsirašykite, kur krenta pirmasis. Pinginkite serverio tunelio adresą – tai įrodo, kad pats tunelis perneša srautą. Pinginkite viešą adresą pagal numerį – tai įrodo persiuntimą ir vertimą neįtraukiant vardų skyrimo. Tada pabandykite išspręsti prieglobos vardą – tai vienintelis testas, kuris naudoja DNS. Kiekvienas rezultatas pašalina visą sluoksnį iš įtarimų.

Nešokite prie trečio testo todėl, kad naršyklė atrodo greitesnė. Nepavykęs puslapio įkėlimas vienu metu uždengia visus tris sluoksnius, ir būtent nuo to pradeda žmonės, o paskui perstato veikusį tunelį. Nepavykęs puslapis nepasako, kuris iš trijų sulūžo.

Du įrašymai parodo, kur sustoja paketai

Kol iš kliento eina ping į viešą adresą, paimkite vieną įrašymą tunelio sąsajoje ir vieną aukštesnėje grandyje, kuri turėtų pasiekti internetą. Paleiskite abu vienu metu, kad laiko žymos sutaptų.

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

Jei užklausos atsiranda tunelyje ir niekada aukštesnėje grandyje, serveris jas numetė tarp tunelio ir laido, o priežastis – persiuntimas arba persiuntimo ugniasienės politika, o ne NAT. Jei jos atsiranda abiejuose, serveris atliko savo dalį, o atsakymo trūksta toliau, kas rodo į vertimą, aukštesnį filtrą arba teikėjo pusės apribojimą.

Aukštesnės grandies pavadinimą imkite iš maršrutizavimo lentelės, o ne iš mokymo. Debesų atvaizdai ir pervardyti adapteriai retai sutampa su vadovo pavyzdine sąsaja, o įrašymas netinkamame įrenginyje atrodo lygiai kaip serveris, kuris nepersiunčia:

ip -4 route get 9.9.9.9

To išvedimo laukas dev yra vardas, kurio NAT taisyklei prireiks vėliau, tad pasilikite jį.

Persiuntimas yra branduolio jungiklis ir ugniasienės politika

Branduolys turi išvis sutikti persiųsti. Perskaitykite dabartinę reikšmę, o tada padarykite nuostatą nuolatinę, o ne įrašykite ją tik į veikiantį branduolį:

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

Persiuntimas yra tik pusė. Hoste su UFW persiuntimo politika nustatoma /etc/default/ufw ir turi būti ACCEPT, kol perkrovimas įsigalios. Numatytasis numetimas persiuntimo kelyje palieka rankos paspaudimą visiškai sveiką, bet tyliai išmeta kiekvieną paketą, kuris bando išeiti per tunelį, ir tai yra būtent tas simptomas, nuo kurio pradėjote.

Hostai, kurie tiesiogiai valdo nftables, susiduria su tuo pačiu klausimu kitoje sintaksėje. Stebėkite persiuntimo grandinės skaitiklius, kol vyksta kliento testas, nes grandinė, į kurią kreipiamasi, ir grandinė, kuri numeta, konfigūracijos faile atrodo vienodai.

NAT taisyklėje įvardykite tikrąją išėjimo sąsają

Šaltinio vertimas priklauso sąsajai, kuri iš tikrųjų palieka hostą, su telkiniu, kurį serveris paskirsto. Abi tos taisyklės pusės turi aprašyti tikrovę, ir nė viena nėra neprivaloma.

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

Klasikinė nesėkmė – taisyklė, nukopijuota iš vadovo, kuri sako -o eth0 mašinoje, kurios adapteris vadinasi kitaip. Taisyklė įdiegiama be įspėjimo, nieko neatitinka, o klientas vis dar neturi interneto. Telkinys – antra tos pačios klaidos pusė: jei serveris paskirsto 10.44.0.0/24, o taisyklė apima 10.8.0.0/24, niekas niekada nesutaps.

Stebėkite skaitiklius, o ne pasitikėkite taisyklės tekstu. Sąrašas praneša paketus pagal taisyklę, o taisyklė, kuri niekada nesutampa, lieka ties nuliu, kad ir kaip teisingai atrodytų. Duokite jai minutę tikro kliento srauto, prieš ką nors spręsdami iš to skaičiaus:

iptables -t nat -L POSTROUTING -v -n

Nulinis paketų skaičius po tikro kliento testo reiškia, kad atitikimas neteisingas, o ne kad tunelis sulaužytas. Kai jis sutaps, išsaugokite taisyklių rinkinį, kad jis išliktų po perkrovimo; pataisa, kuri gyvena tik jūsų shell istorijoje, dingsta per pirmą perkrovimą.

Jei serveris taip pat yra debesų NAT egzempliorius, platforma taip pat turi žodį. Egzemplioriui, kuris verčia adresus, paprastai reikia išjungtos šaltinio ir paskirties patikros ten, kur teikėjas siūlo tą nuostatą, o pats VPN prievadas turi būti pasiekiamas iš išorės.

DNS yra antroji nesėkmė už pirmosios

Pingas pagal adresą veikia, o vardai krenta – tai sprendėjo problema, ir ji turi savo priežastį. Klientas, kuris pasilieka savo vietinį sprendėją, siunčia tas užklausas į pilną tunelį ir laukia atsakymo, kuris niekada neateina, nes vietinis sprendėjas dabar yra neteisingoje maršruto pusėje.

Nusiųskite sprendėją iš serverio, kad klientas žinotų, kur klausti. Du įrašai duoda klientui atsarginį variantą, jei pirmasis nepasiekiamas, ir abu turėtų būti sprendėjai, kuriuos tunelis iš tikrųjų leidžia.

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

Windows klientai vis tiek gali grįžti prie vietinio sprendėjo, ir būtent tam egzistuoja block-outside-dns, tačiau už vardų, kuriuos gali išspręsti tik vietinis tinklas, praradimo kainą. Linux klientai su systemd-resolved dažnai ignoruoja nusiųstą sprendėją, nebent scenarijus jį įdiegia, tad prieš darydami išvadą, kad siuntimas buvo ignoruotas, patikrinkite resolvectl status tunelio įrenginiui.

Užbaikite ėjimą taip, kaip jį patiria naudotojas. Įkelkite tikrą puslapį iš kliento, patvirtinkite, iš kokio adreso jis išeina, perkraukite serverį, prisijunkite iš naujo ir pakartokite tris testus. Tik tas antrasis ratas įrodo, kad išsaugotos taisyklės, ugniasienės politika ir nusiųstas sprendėjas visi kartu išliko.