Pieslēgts pie OpenVPN, bet nekas neielādējas: gājiens no klienta uz āru

Klienta logā rakstīts Connected, tuneļa adrese ir, un pārlūks joprojām griežas. Šī kombinācija ir normāla, jo veiksmīga roku saspišana pierāda tikai to, ka tunelis ir uzbūvēts; tas neko nepasaka par to, vai serveris pārsūtīs jūsu paketes, pārrakstīs to avotu vai atbildēs uz jūsu DNS vaicājumiem. Lielākās daļas cilvēku kļūda ir vispirms atvērt servera konfigurāciju. Tā vietā strādājiet no klienta uz āru, jo katrs solis zemāk pasaka, vai nākamo vispār ir vērts pārbaudīt.

Sāciet pie klienta un ejiet uz āru

Veiciet trīs testus šajā secībā un pierakstiet, kur pirmais neizdodas. Pingojiet servera tuneļa adresi, kas pierāda, ka pats tunelis pārvadā satiksmi. Pingojiet publisku adresi pēc numura, kas pierāda pārsūtīšanu un tulkošanu, neiesaistot vārdu izšķiršanu. Pēc tam mēģiniet atrisināt resursdatora vārdu, kas ir vienīgais tests, kurš izmanto DNS. Katrs rezultāts noņem veselu slāni no aizdomām.

Neleciet uz trešo testu tāpēc, ka pārlūks šķiet ātrāks. Neizdevies lapas ielāde nosedz visus trīs slāņus uzreiz, un tieši no tā cilvēki sāk un pēc tam pārbūvē strādājošu tuneli. Neizdevusies lapa nepasaka, kurš no trim salūza.

Divi ieraksti parāda, kur paketes apstājas

Kamēr no klienta iet ping uz publisku adresi, veiciet vienu ierakstu tuneļa saskarnē un vienu augšupējā saitē, kurai būtu jāsasniedz internets. Palaidiet abus vienlaikus, lai laika zīmogi sakristu.

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

Ja pieprasījumi parādās tunelī un nekad augšupējā saitē, serveris tos ir nometis starp tuneli un vadu, un cēlonis ir pārsūtīšana vai pārsūtīšanas ugunsmūra politika, nevis NAT. Ja tie parādās abos, serveris ir izdarījis savu daļu, un atbilde trūkst tālāk, kas norāda uz tulkošanu, augšupēju filtru vai pakalpojumu sniedzēja puses ierobežojumu.

Augšupējās saites nosaukumu ņemiet no maršrutēšanas tabulas, nevis no apmācības. Mākoņu attēli un pārdēvēti adapteri reti sakrīt ar rokasgrāmatas piemēra saskarni, un ieraksts nepareizajā ierīcē izskatās tieši kā serveris, kas nepārsūta:

ip -4 route get 9.9.9.9

Lauks dev šajā izvadē ir nosaukums, kas NAT noteikumam būs vajadzīgs vēlāk, tāpēc saglabājiet to.

Pārsūtīšana ir kodola slēdzis un ugunsmūra politika

Kodolam vispirms jāpiekrīt pārsūtīt. Nolasiet pašreizējo vērtību un pēc tam padariet iestatījumu pastāvīgu, tā vietā lai rakstītu to tikai darbojošā kodolā:

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

Pārsūtīšana ir tikai puse. Resursdatorā ar UFW pārsūtīšanas politika tiek iestatīta /etc/default/ufw un tai jābūt ACCEPT, pirms pārlāde stājas spēkā. Noklusējuma nomešana pārsūtīšanas ceļā atstāj roku saspišanu pilnīgi veselu, bet klusi izmet katru paketi, kas mēģina iziet caur tuneli, un tas ir tieši tas simptoms, ar kuru sākāt.

Resursdatori, kas pārvalda nftables tieši, saskaras ar to pašu jautājumu citā sintaksē. Vērojiet pārsūtīšanas ķēdes skaitītājus, kamēr notiek klienta tests, jo ķēde, kurai jautā, un ķēde, kas nomet, konfigurācijas failā izskatās vienādi.

NAT noteikumā nosauciet īsto izejas saskarni

Avota tulkošana pieder saskarnei, kas patiešām atstāj resursdatoru, kopā ar kopu, ko serveris izdala. Abām šī noteikuma pusēm jāapraksta realitāte, un neviena nav obligāta.

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

Klasiskā neveiksme ir noteikums, kas nokopēts no rokasgrāmatas un saka -o eth0 mašīnā, kuras adapteris saucas citādi. Noteikums tiek instalēts bez brīdinājuma, neatbilst nekam, un klientam joprojām nav interneta. Kopa ir otras pusītes tā pati kļūda: ja serveris izdala 10.44.0.0/24 un noteikums aptver 10.8.0.0/24, nekas nekad nesakritīs.

Vērojiet skaitītājus, nevis uzticieties noteikuma tekstam. Saraksts ziņo paketes uz noteikumu, un noteikums, kas nekad nesakrīt, paliek uz nulles, lai cik pareizs tas izskatītos. Dodiet tam minūti īstas klienta satiksmes, pirms kaut ko secināt no šī skaitļa:

iptables -t nat -L POSTROUTING -v -n

Nulle pakešu pēc īsta klienta testa nozīmē, ka atbilstība ir nepareiza, nevis ka tunelis ir salauzts. Tiklīdz tas sakrīt, saglabājiet noteikumu kopu, lai tā pārdzīvotu restartu; labojums, kas dzīvo tikai jūsu čaulas vēsturē, pazūd pirmajā restartā.

Ja serveris ir arī mākoņa NAT instance, arī platformai ir vārds. Instancei, kas tulko adreses, parasti nepieciešama izslēgta avota un galamērķa pārbaude tur, kur pakalpojumu sniedzējs piedāvā šo iestatījumu, un pašam VPN portam jābūt sasniedzamam no ārpuses.

DNS ir otrā neveiksme aiz pirmās

Pings pēc adreses strādā, kamēr vārdi neizdodas – tā ir risinātāja problēma, un tam ir savs cēlonis. Klients, kas patur savu vietējo risinātāju, sūta šos vaicājumus pilnā tunelī un gaida atbildi, kas nekad nenāk, jo vietējais risinātājs tagad ir maršruta nepareizajā pusē.

Nosūtiet risinātāju no servera, lai klients zinātu, kur jautāt. Divi ieraksti dod klientam rezervi, ja pirmais nav sasniedzams, un abiem jābūt risinātājiem, ko tunelis patiešām atļauj.

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

Windows klienti pēc tam var tomēr atgriezties pie vietējā risinātāja, un tieši to block-outside-dns pastāv, lai novērstu, par cenu zaudēt vārdus, ko var atrisināt tikai vietējais tīkls. Linux klienti ar systemd-resolved bieži ignorē nosūtīto risinātāju, ja vien skripts to neinstalē, tāpēc pirms secināt, ka nosūtīšana tika ignorēta, pārbaudiet resolvectl status tuneļa ierīcei.

Pabeidziet gājienu tā, kā to piedzīvo lietotājs. Ielādējiet īstu lapu no klienta, apstipriniet adresi, no kuras tā iziet, restartējiet serveri, pievienojieties vēlreiz un atkārtojiet trīs testus. Tikai šis otrais riņķis pierāda, ka saglabātie noteikumi, ugunsmūra politika un nosūtītais risinātājs visi kopā ir izturējuši.