VPN klienti pieslēdzas, bet interneta nav: trīs trūkstošas daļas

Klients iegūst adresi, serveris atbild uz ping, un tomēr katra lapa beidzas ar taimautu. Lielākā daļa cilvēku šajā brīdī sāk rediģēt klienta profilu, kas parasti ir veltīgs darbs: kad tunelis ir pacelts, serverim jāuzvedas kā maršrutētājam. Trim nosacījumiem jābūt izpildītiem vienlaikus, lai pakete izietu un atgrieztos atbilde, un simptoms ir vienāds neatkarīgi no tā, kura trūkst.

Kāpēc strādājošam tunelim joprojām nav izejas

Kodolam ir jāpāradresē paketes starp saskarnēm, un tas vairumā Linux distribūciju pēc noklusējuma ir izslēgts. Trafiks ir jāpārtulko uz adresi, uz kuru ārpasaule var atbildēt, ja vien katrs augšupējais maršrutētājs jau nezina atgriešanās ceļu uz tuneļa apakštīklu. Ugunsmūra pāradresācijas ceļam jāatļauj trafiks abos virzienos, tostarp atbildes.

Katra no tām ir labojama atsevišķi, un tieši tā ir slazds. Ieslēdzot pāradresāciju bez tulkošanas noteikuma, paketes iziet ar privātu avotu un bez atgriešanās ceļa. Pievienojot tulkošanu bez pāradresācijas noteikuma, kodols paketi nomet vienu soli vēlāk.

Tāpēc pārbaudiet trīs slāņus, nevis klientu, un mainiet pa vienam, lai rezultātam būtu nozīme.

Pāradresācija ir kodola slēdzis, kas jāpadara pastāvīgs

Pirms maiņas pārbaudiet pašreizējo vērtību, pēc tam iestatiet to un apstipriniet, ka izmaiņas stājās spēkā.

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
sysctl net.ipv4.ip_forward

Pirmā komanda ziņo pašreizējo vērtību, otrā to iestata izpildlaikā, un trešā pierāda, ka rakstīšana nostrādāja. Izpildlaika vērtība pazūd nākamajā pārstartēšanā, tāpēc strādājoša sesija pēc apkopes var salūzt bez jebkādām konfigurācijas izmaiņām.

Padariet to pastāvīgu failā zem /etc/sysctl.d/, pēc tam piemērojiet šo failu, nevis pārstartējiet, lai uzzinātu. FreeBSD ekvivalents ir net.inet.ip.forwarding, un pastāvībai — gateway_enable=YES failā rc.conf. Ierīce, kas ziņo par izslēgtu pāradresāciju, izskaidro veselu ziņojumu klasi „paketes ierodas, un nekas neatgriežas”. Pārbaudiet iestatījumu arī pēc katras atjaunināšanas, jo pārbūvēts kodols vai nomainīts ierīces attēls var to atiestatīt, nevienam nepasakot.

Izvēlieties masquerade vai vienu fiksētu tulkošanas adresi

Ar dinamisku ārējo adresi masquerading ir vienkāršākā pareizā forma. Norādiet tuneļa apakštīklu kā avotu un ārējo saskarni kā izeju.

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -o eth0 -j MASQUERADE

Ar statisku publisku adresi avota tulkošana tieši uz šo adresi ir paredzamāka un vieglāk auditējama.

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -j SNAT --to-source 198.51.100.10

Otrajai formai ir apkopes slazds: cieti kodēta adrese, kas vēlāk mainās, uztur tuneli darbā, kamēr piekļuve internetam klusi apstājas. Vai nu izmantojiet masquerade, vai atjauniniet noteikumu ikreiz, kad pakalpojumu sniedzējs jūs pārvieto. Saskarnei arī ir nozīme, jo maršrutētājam, kas dala savu augšupējo tuneli, ir jātulko pa šo tuneli, nevis pa fizisko WAN.

Filtru tabula ir trešie vārti

Pāradresācija un tulkošana var būt abas pareizas, kamēr pakete tomēr mirst filtru tabulā. ufw ir biežs vaininieks: tā pāradresācijas politika tiek piegādāta kā DROP, un pārējā iestatīšana var izskatīties pilnīgi pareiza, kamēr tas viens iestatījums nogalina trafiku. To pacelt ir apzināts drošības lēmums, nevis atzīmēšanas rūtiņa.

iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Pirmais noteikums atļauj jaunu trafiku no tuneļa uz āru, un otrais — tikai atbildes atpakaļ. Sašauriniet abus līdz tuneļa apakštīklam un paredzētajam galamērķim, jo vispārēja atļauja tuneļa saskarnē pārvērš VPN par atvērtu izejas punktu ikvienam, kas spēj autentificēties.

Tiltots tunelis prasa citu atbildi. Adrese pieder tiltam, nevis fiziskajai pieslēgvietai, tāpēc saskarnes pakļaušana noņem iepriekšējo adresi, un saimnieks izskatās nesasniedzams, līdz pats tilts iegūst adresi, ko var nodrošināt dhclient br0. Šī kļūme izskatās kā VPN problēma, bet ir otrā slāņa problēma. Pārbaudiet paša tilta adresi, pirms pieskaraties ugunsmūrim, jo filtra izmaiņas nevar salabot saimnieku, kuram vairs nav adreses, no kuras sūtīt.

Kur skatīties, kad lapa nekad neielādējas

Pingojiet servera tuneļa adresi, lai pierādītu, ka tunelis pastāv. Pēc tam palaidiet traceroute no klienta uz publisku adresi un izlasiet, kur tas apstājas: serverī pakete ierodas, bet netiek pāradresēta vai tulkota; aiz servera problēma ir augšup un ārpus jūsu rokām.

ping -c 3 10.9.0.1
traceroute -n 198.51.100.10

Pirmā komanda pierāda, ka tunelis nes trafiku līdz pašam serverim, un otrā parāda, cik tālu pakete nokļūst ārpusē. Pēda, kas beidzas tuneļa adresē, norāda uz pāradresāciju vai tulkošanu serverī, savukārt pēda, kas apstājas vienu lēcienu vēlāk, norāda uz pakalpojumu sniedzēju vai augšupējā maršrutētāja atgriešanās ceļu.

Serverī vērojiet ārējo saskarni, kamēr klients ielādē lapu. Trafiks, kas iziet ar privātu avota adresi, nozīmē, ka trūkst tulkošanas, un pilnīga atbildes neesamība nozīmē, ka to nomet pāradresācijas ceļš vai augšupējais atgriešanās maršruts.

Ja attālinātajiem klientiem jāsasniedz arī servera LAN saimnieki, atcerieties, ka LAN vajag atgriešanās maršrutu uz tuneļa apakštīklu. Tas ir maršrutēšana, nevis tulkošana, un tas ir solis, kas visbiežāk tiek aizmirsts pēc tam, kad interneta ceļš beidzot strādā.