VPN-klientoj konektiĝas sed ne havas interreton: tri mankantaj pecoj

La kliento ricevas adreson, la servilo respondas al ping, kaj ĉiu paĝo tamen tempolimas. Plej multaj homoj komencas redakti la klientan profilon ĉi tie, kio kutime estas vana peno: post kiam la tunelo staras, la servilo devas konduti kiel enkursigilo. Tri kondiĉoj devas validi samtempe antaŭ ol paketo eliras kaj respondo revenas, kaj la simptomo estas identa kiu ajn mankas.

Kial funkcianta tunelo ankoraŭ ne havas eliron

La kerno devas plusendi pakaĵojn inter interfaĉoj, kio estas defaŭlte malŝaltita en plej multaj Linuksaj distribuaĵoj. La trafiko devas esti tradukata al adreso, kiun la ekstera mondo povas respondi, krom se ĉiu supra enkursigilo jam konas la revenan vojon al la tunela subreto. La plusenda vojo de la fajroŝirmilo devas permesi la trafikon en ambaŭ direktojn, inkluzive de la respondoj.

Ĉiu el tiuj povas esti riparita sendepende, kaj tio estas la kaptilo. Ŝalti plusendadon sen traduka regulo lasas pakaĵojn eliri kun privata fonto kaj sen revena vojo. Aldoni tradukadon sen plusenda regulo lasas la kernon faligi la pakaĵon unu paŝon poste.

Do testu la tri tavolojn anstataŭ la klienton, kaj ŝanĝu unu samtempe, por ke la rezulto signifu ion.

Plusendado estas kernŝaltilo, kiun vi devas daŭrigi

Kontrolu la nunan valoron antaŭ ol ŝanĝi ĝin, poste agordu ĝin kaj konfirmu, ke la ŝanĝo efikis.

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

La unua komando raportas la nunan valoron, la dua agordas ĝin dum funkciado, kaj la tria pruvas, ke la skribo funkciis. La valoro dum funkciado malaperas ĉe la sekva restarto, pro kio funkcianta sesio povas rompiĝi post bontenado sen ajna agorda ŝanĝo.

Faru ĝin daŭra en dosiero sub /etc/sysctl.d/, poste apliku tiun dosieron anstataŭ restartigi por ekscii. En FreeBSD la ekvivalento estas net.inet.ip.forwarding, kun gateway_enable=YES en rc.conf por daŭro. Aparato, kiu raportas plusendadon malŝaltita, klarigas tutan klason de raportoj „pakaĵoj alvenas kaj nenio revenas”. Kontrolu la agordon ankaŭ post ĉiu ĝisdatigo, ĉar rekonstruita kerno aŭ anstataŭigita aparata bildo povas restarigi ĝin sen diri al iu.

Elektu masquerade aŭ unu fiksan tradukan adreson

Kun dinamika ekstera adreso, masquerading estas la plej simpla ĝusta formo. Nomu la tunelan subreton kiel fonton kaj la eksteran interfaĉon kiel eliron.

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

Kun statika publika adreso, fonta tradukado al ĝuste tiu adreso estas pli antaŭvidebla kaj pli facile revidebla.

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

La dua formo portas bontenan kaptilon: fikskodigita adreso, kiu poste ŝanĝiĝas, tenas la tunelon funkcianta dum interreta aliro silente haltas. Aŭ uzu masquerade aŭ ĝisdatigu la regulon ĉiufoje, kiam la provizanto movas vin. La interfaĉo ankaŭ gravas, ĉar enkursigilo, kiu dividas sian propran supran tunelon, devas traduki tra tiu tunelo kaj ne tra la fizika WAN.

La filtra tabelo estas la tria pordego

Plusendado kaj tradukado povas ambaŭ esti ĝustaj dum la pakaĵo tamen mortas en la filtra tabelo. ufw estas ofta kulpulo: ĝia plusenda politiko venas kiel DROP, kaj la resto de la agordo povas aspekti tute ĝusta dum tiu unu agordo mortigas la trafikon. Altigi ĝin estas konscia sekureca decido, ne markobutono.

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

La unua regulo permesas novan trafikon de la tunelo al la ekstero, kaj la dua nur respondojn reen. Mallarĝigu ambaŭ al la tunela subreto kaj la celita celo, ĉar ĝenerala permeso ĉe la tunela interfaĉo igas la VPN malfermita elirejo por iu ajn, kiu povas aŭtentigi.

Ponta tunelo bezonas alian respondon. La adreso apartenas al la ponto, ne al la fizika pordo, do sklavigi la interfaĉon forigas la adreson, kiun ĝi antaŭe havis, kaj la gastiganto aspektas neatingebla ĝis la ponto mem ricevas unu, kiun dhclient br0 povas provizi. Tiu fiasko aspektas kiel VPN-problemo kaj estas problemo de la dua tavolo. Kontrolu la propran adreson de la ponto antaŭ ol tuŝi la fajroŝirmilon, ĉar filtra ŝanĝo ne povas ripari gastiganton, kiu jam ne havas adreson por sendi.

Kien rigardi, kiam paĝo neniam ŝarĝiĝas

Ping la tunelan adreson de la servilo por pruvi, ke la tunelo ekzistas. Poste rulu traceroute de la kliento al publika adreso kaj legu, kie ĝi haltas: ĉe la servilo la pakaĵo alvenas sed ne estas plusendata nek tradukata; preter la servilo la problemo estas supra kaj ekster viaj manoj.

ping -c 3 10.9.0.1
traceroute -n 198.51.100.10

La unua komando pruvas, ke la tunelo portas trafikon al la servilo mem, kaj la dua montras, kiom malproksimen pakaĵo iras eksteren. Spuro finiĝanta ĉe la tunela adreso montras plusendadon aŭ tradukadon ĉe la servilo, dum spuro haltanta unu salteton poste montras la provizanton aŭ la revenan vojon de la supra enkursigilo.

Ĉe la servilo observu la eksteran interfaĉon dum kliento ŝarĝas paĝon. Trafiko eliranta kun privata fonta adreso signifas, ke tradukado mankas, kaj tute neniu respondo signifas, ke la plusenda vojo aŭ la supra revena itinero faligas ĝin.

Se remotaj klientoj devas ankaŭ atingi gastigantojn en la LAN de la servilo, memoru, ke la LAN bezonas revenan itineron al la tunela subreto. Tio estas enkursigado, ne tradukado, kaj ĝi estas la paŝo plej ofte forgesata post kiam la interreta vojo fine funkcias.