Maršrutētāja VPN darbojas, bet LAN klientiem nav interneta

Statuss vēsta, ka tunelis ir pacelts, pārlūks pašā maršrutētājā ielādē lapas, bet katra ierīce aiz tā joprojām pārsniedz laika limitu. Šī kombinācija sašaurina problēmu līdz slānim, ko lielākā daļa VPN ceļvežu nekad nemin: maršrutētājs nav vienīgais hosts, kura paketēm jāiztur tunelis. Lokāli ģenerētā plūsma un pāradresētā plūsma iet dažādus ceļus caur vienu un to pašu kārbu. Pārbaudiet no klienta, un atšķirība pārstāj būt teorētiska.

Lasiet kļūmi no LAN hosta

Sāciet ar ierīci, kas neizdodas, jo maršrutētājā veikta diagnostika atbild uz citu jautājumu. Apstipriniet, ka klienta noklusējuma vārteja ir šis maršrutētājs, pierakstiet tā avota adresi un apakštīklu, pēc tam aplūkojiet, kas iziet no maršrutētāja tuneļa saskarnes.

Ja klienta adrese tiek tulkota, attālā puse redz tuneļa adresi, un no turienes viss izskatās veselīgi, kamēr klients joprojām neizdodas. Ja tā netiek tulkota, attālajai pusei jāzina maršruts atpakaļ uz klienta apakštīklu, un daudzām vārstēm šāds maršruts pēc noklusējuma nav. Jebkurā gadījumā paša maršrutētāja panākumi nav svarīgi, jo tā paketes tika ģenerētas lokāli un nekad nav gājušas pa pāradresācijas ceļu.

Lokālā un pāradresētā plūsma atšķiras

Linux un lielākā daļa maršrutētāju programmaparatūras paketes, kas radušās pašā kārbā, apstrādā citādi nekā paketes, kas iet caur to. Izvades ķēde redz pirmo veidu, pāradresācijas ķēde redz otro, un politika, kas pielāgota paša maršrutētāja plūsmai, var atstāt pāradresāciju neskartu.

sysctl net.ipv4.ip_forward
ip -4 address show br-lan
ip route get 203.0.113.9
nft list ruleset | grep -A 6 'chain forward'

Pārbaudiet, vai pāradresācija vispār ir iespējota, pēc tam lasiet pāradresācijas ķēdi, nevis izvades ķēdi. Noteikums, kas atļauj šifrēto ārējo savienojumu, nav noteikums, kas atļauj pāradresēt atšifrētas paketes, un šo divu sajaukšana rada tieši šo simptomu. Tas, ka tunelis ir pacelts, pierāda tikai pirmo.

Atgriešanās ceļam arī jāpastāv

Avota tulkošana izlemj, vai atgriešanās ceļš ir vajadzīgs. Ja tuneļa saskarnē ir maskēšana, atbildes nāk atpakaļ uz tuneļa adresi, un maršrutētājs tās iztulko atpakaļ. Bez tās attālajai vārtejai vajadzīgs skaidrs maršruts uz klienta apakštīklu, un tās pašas politikai jāatļauj šis virziens.

Pirms kaut ko mainīt, pierakstiet, kuru no divām konstrukcijām izmanto izvietojums, jo labojumi vērsti pretējos virzienos. Tulkošanas pievienošana paslēpj trūkstošu atgriešanās maršrutu un salauž lietojumprogrammas, kurām vajadzīga sākotnējā avota adrese. Atgriešanās maršruta pievienošana bez tulkošanas klusi neizdodas, kad attālais ugunsmūris atmet nepazīstamu avotu. Izvēlieties vienu, dokumentējiet un saskaņojiet otru pusi.

Klienta DNS pieder tai pašai pārbaudei. Maršrutētāja risinātājs var atbildēt, kamēr klients, kas norāda uz citu serveri, nesaņem neko.

Pārbaudiet vienu atļautu un vienu aizliegtu plūsmu

Pēc labojuma izmēģiniet jaunu savienojumu no klienta, nevis esošu maršrutētāja sesiju. Pēc tam apstipriniet, ka segments, kuram nevajadzētu izmantot tuneli, joprojām to neizmanto.

curl -sS --max-time 8 https://api.ipify.org
ip route get 203.0.113.9
dig +short intranet.example.net

Pārbaudiet novēroto avota adresi attālajā galā, jo tā pasaka, kura konstrukcija patiešām darbojas. Pārbaudiet gan nosaukuma meklēšanu, gan adresi, jo risinātāja uzvedība ir atsevišķs ceļš caur to pašu kārbu.

Turiet noteikumus ierobežotus ar klientu tīkliem, kuriem vajadzīgs tunelis, un pretstājieties kārdinājumam izslēgt pāradresācijas filtru, lai viens tests izietu. Šīs izmaiņas salabo testu un noņem robežu, kuru tunelim bija jānodrošina. Pierakstiet avota adresi, tulkošanas lēmumu un atgriešanās maršrutu vienā piezīmē ar datumu.