Masquerade aŭ politika vojigo: LAN-trafiko tra VPN-pordego

Meti tutan LAN malantaŭ VPN-tunelon estas la facila parto; decidi, kiel la malproksima flanko vidas tiujn klientojn, ne estas. Masquerade reskribas ĉiun LAN-fonton al la tunela adreso de la pordego, do la fora fino respondas al unu samtavolano. Politika vojigo konservas la originajn adresojn kaj postulas, ke la fora fino sciu, kiel atingi ilin. Neniu el la du estas defaŭlta; la elekto sekvas el tio, kiu posedas la malproksiman flankon kaj ĉu identeco laŭ aparato gravas.

La du dezajnoj promesas malsamajn aferojn

Masquerade reduktas la LAN al unu videbla gastiganto: la pordego. La fora reto respondas al tiu unu adreso, kaj la pordego tradukas la respondojn reen al la kliento, kiu komencis la fluon. Neniu vojo al viaj privataj prefiksoj necesas ĉe la fora flanko, kaj tial ĉi tiu dezajno postvivas provizanton, kiu rifuzas porti ilin. La pordego ankaŭ iĝas la fonto de ĉiu konekto, do la fora flanko ne povas distingi du klientojn.

Politika vojigo konservas ĉiun klientan adreson sendifekta. La fora reto vidas la realan fonton kaj povas registri ĝin, apliki regulon laŭ gastiganto aŭ sendi la respondon rekte al tiu adreso. Tiu videbleco estas la tuta celo, kaj ĝi venas kun devo: la fora flanko devas havi vojon por la LAN-prefikso, kiu montras reen tra la tunelo. Planu tiun vojon antaŭ ol vi ebligos la regulon, ĉar la tunelo leviĝos ĉiuokaze kaj mankos nur la respondoj.

La malsukcesaj reĝimoj diferencas tiom, kiom la promesoj. Mankanta masquerade-regulo produktas pakaĵojn, kiuj eliras kun privataj fontoj kaj neniam revenas. Mankanta revena vojo produktas la saman simptomon sub politika vojigo, sed la korekto apartenas al la fora enkursigilo, ne al la pordego.

Masquerade: unu samtavolano ĉe la fora flanko

La masquerade-vojo havas ordon, kiu gravas. Plusendado devas esti ebligita antaŭ ol iu ajn NAT-regulo utilas, la filtra tabelo devas permesi la trairon en ambaŭ direktoj, kaj nur tiam la traduko aplikiĝas sur la tunela interfaco.

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i eth1 -o tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

La klientoj ankoraŭ bezonas vojon al la pordego. Aŭ la pordego estas ilia defaŭlta enkursigilo, aŭ ili portas specifan vojon por la fora prefikso; se aparta enkursigilo restas la defaŭlto, tiu enkursigilo bezonas statikan vojon por la tunelaj celoj, alie la pakaĵo iras al la malĝusta salto antaŭ ol la pordego vidas ĝin.

DNS estas aparta decido. Solvilo ĉe la fora flanko respondas nur se ĝia respondo povas vojaĝi reen al la kliento. Sub masquerade la demando ŝajnas veni de la pordego, do la revena vojo de la solvilo jam estas kontentigita; sub politika vojigo la solvilo bezonas la saman revenan vojon kiel ĉiu alia fora servo.

Politika vojigo: konservu la fonton, aldonu revenan vojon

Politika vojigo komenciĝas per tabelo kaj regulo, kiu elektas ĝin. Trafiko eniranta de la LAN-interfaco estas sendata al dediĉita tabelo, kaj tiu tabelo portas defaŭltan vojon tra la tunelo. La ĉefa tabelo restas netuŝita, do trafiko originita de la pordego mem povas sekvi alian vojon.

ip rule add iif eth1 table vpn
ip route add default dev tun0 table vpn

La fora flanko tiam devas voji la LAN-prefikson reen tra la tunelo. Tio estas agordo ĉe la fora enkursigilo, ne ĉe ĉi tiu pordego. La pordego ankaŭ devas akcepti respondojn, kiuj alvenas sur alia interfaco ol tiu, kiun la ĉefa tabelo antaŭvidus; loza inversvoja filtrado (rp_filter agordita al 2) estas la kutima ĝustigo, kiam strikta reĝimo forĵetas tiujn pakaĵojn.

Kiam du tuneloj estas aktivaj, marku ĉiun fluon ĉe la eniro kaj lasu la markon elekti la tabelon. Regulo, kiu rigardas nur la enigInterfacon, sendas la trafikon de ambaŭ tuneloj al la sama tabelo, do la dua tunelo ŝtelas fluojn de la unua. Testu tiun markon per konekto, kiu postvivas rekonekton, ĉar tiam montriĝas miksa politiko.

Decidu laŭ posedo kaj laŭ tio, kion registras la fora flanko

Se la tunelo finiĝas ĉe provizanto, uzu masquerade. Tiu operatoro ne vojigos viajn privatajn LAN-rangojn, kaj ĝi havas neniun kialon distingi unuopajn klientojn malantaŭ via pordego. Unu videbla samtavolano estas la sola modelo, kiun ĝia politiko subtenas, do donu ĝin al ĝi kaj tenu la tradukon ĉe via rando. La provizanto vidas unu samtavolanon, kio estas ĝuste kion ĝia politiko atendas, kaj viaj klientoj heredas tiun unu identecon.

Se ambaŭ finoj estas viaj kaj la foraj servoj agas laŭ fontaj adresoj, politika vojigo meritas sian plian vojon. Fajroŝirmaj reguloj, alirado laŭ uzanto kaj reviziaj protokoloj povas tiam distingi klientojn. Se la fora flanko bezonas nur atingeblon, masquerade estas pli simpla kaj forigas tutan klason de revenvoja eraro.

Hibridaj dezajnoj estas normalaj: politika vojigo ene de via propra reto, masquerade ĉe la provizanta rando. Gravas skribi, kiu salto tradukas kaj kiu salto vojigas, ĉar hazarda NAT-regulo aldonita por unu kliento kaŝas la fonton por ĉiu kliento en la sama ĉeno.

Kontrolu el unu kliento, poste el dua kliento

Rulu la teston tie, kie la trafiko komenciĝas. Kontrolu la vojon, kiun la gastiganto uzas, observu la pakaĵon aperi sur la tunela interfaco kaj ekzamenu conntrack por la traduko. Tiu sinsekvo pruvas, ke la pakaĵo prenis la celitan vojon, ne simple alvenis ie.

Ripetu la teston post rekonekto. Masquerade-regulo, kiu nomas la interfacon, postvivas novan tunelan adreson; regulo, kiu nomas la malnovan adreson, ne postvivas. Poste testu duan LAN-gastiganton, ĉar dezajno, kiu funkcias sur unu maŝino, ofte dependas de la propra vojo de tiu maŝino, ne de la pordega politiko.

Skribu la elektitan modelon, la tradukitan aŭ konservitan fonton kaj la posedanton de la revena vojo en la pordegajn notojn. Alie la sekva persono, kiu aldonas klienton aŭ tunelon, divenos, kaj diveno estas kiel funkcianta LAN-al-VPN-agordo fariĝas parta.