Kunhavigi unu VPN-konekton kun ĉiu aparato en via LAN

Kunhavigi tunelon postulas plusendadon, tradukadon kaj revenan itineron. Komparu gastigan kunhavigon, enkursigan itineron al tiu gasto, kaj pordegon kiu posedas la tunelon.

Unu tekkomputilo tenas la tunelon, la resto de la domo volas la saman aliron, kaj la unua provo estas direkti ĉion al la konektita maŝino. Ĝi malsukcesas pro kialoj tute ne rilataj al la VPN: la ricevanta gasto devas plusendi la paketon, reverki ĝian fonton, kaj certigi ke respondoj trovos la vojon reen. Manku eĉ unu el la tri, kaj la konektita tekkomputilo daŭre funkcias dum ĉiu alia aparato atingas tempolimon. La solvo estas enkursiga projektado, ne klienta agordo.

Kial direkti aparatojn al la gasto malsukcesas

Gasto kiu ricevas paketon adresitan al fora reto fariĝas enkursigilo por tiu momento, ĉu iu agordis ĝin tiel aŭ ne. Plusendado estas defaŭlte malŝaltita en Linux kaj en Windows krom se funkcio ŝaltas ĝin. Tradukado gravas ĉar la fora flanko devas scii kien sendi respondojn, kaj privata LAN-adreso signifas nenion por ĝi. La reena itinero estas la tria peco, kaj ĝin homoj forgesas kiam la unua ping ŝajnas sukcesi.

Diagnozu laŭ tiu ordo anstataŭ ŝalti agordojn hazarde. Ĉiu mankanta peco produktas iomete alian simptomon.

Ŝaltu plusendadon kaj tradukadon sur la gasto

Du ŝanĝoj sur la konektita gasto kovras la unuajn du pecojn: ŝaltu IPv4-plusendadon kaj traduku la LAN-trafikon al la tunela interfaco.

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

Konservu la valoron sysctl en dosiero sub /etc/sysctl.d, kaj rekontrolu la regulon MASQUERADE post restartiĝo, ĉar fajroŝirmilaj fasadoj povas purigi proprajn ĉenojn. En Windows la kunhaviga funkcio plenumas ambaŭ paŝojn, sed ĝi ankaŭ readresigas la LAN-adaptilon al fiksa subreto kaj forigas ĝian pordegon, kio rompas statikan adresadon kaj pordplusendadon. Restarigu la vojon de la enkursigilo al la gasto ĉe ĝia nova adreso antaŭ ol konkludi ke kunhavigo malsukcesis. Poste observu la regulajn nombrilojn kreski dum dua aparato sendas trafikon.

Donu al la LAN vojon kiu postvivas restartojn

La aliaj aparatoj bezonas itineron al la fora prefikso, kaj la du manieroj provizi ĝin diferencas laŭ efika amplekso.

ip route add 10.8.0.0/24 via 192.168.1.20 dev eth0

Direkti la defaŭltan pordegon de kliento al la gasto sendas ĝian tutan trafikon tra la gasto, inkluzive lokan presadon kaj dosierkunhavigon, do nerilataj aferoj haltas kiam la gasto dormas. Aldoni specifan itineron sur la enkursigilo por la fora prefikso estas pli mallarĝa: nur celoj malantaŭ la tunelo iras al la konektita maŝino, kaj la resto de la LAN daŭre funkcias. La subretoj supre estas ekzemploj, do anstataŭigu ilin per viaj propraj LAN kaj tunelaj intervaloj. Ĉiukaze, testu de dua aparato kun la tunelo ŝaltita kaj poste malŝaltita.

Rigardu la MTU antaŭ ol kulpigi la tunelon

Tuneloj malgrandigas la uzeblan paketgrandon, kaj la dua aparato tute ne scias tion. Grandaj transigoj kaj TLS-manpremoj haltas dum malgrandaj petoj sukcesas.

ping -M do -s 1400 10.8.0.5

Respondo pruvas ke tiu grandeco trapasas la vojon sen fragmentado; tempolimo signifas ke enkapsuliga superkosto puŝis la paketon preter la MTU de la tunelo. Malaltigu la MTU sur la kunhaviga interfaco aŭ limigu la maksimuman segmentan grandecon sur la plusendilo, kaj poste ripetu la saman provon. Testu la saman grandecon unue ĉe la LAN-flanko, ĉar loka malsukceso indikas la LAN kaj ne la tunelon. Notu la funkciantan grandecon, ĉar posta provizanta aŭ tunela ŝanĝo povas movi ĝin.

Por unu plia aparato sufiĉas gastiga kunhavigo. Por domanaro metu la itineron sur la enkursigilon. Kiam aliro devas postvivi ke la tekkomputilo foriras kun vi, la tunelo mem apartenas al dediĉita pordego.

Rilataj artikoloj