Atingi malproksiman /24 tra tunelo: NETMAP, DNAT aŭ vojo?
Mapu tutan prefikson per NETMAP, aldonu DNAT-regulojn por ĉiu gastiganto aŭ voju la realan gamon, kaj decidu laŭ tio, kion la malproksima flanko devas vidi kaj kiu rajtas komenci trafikon.
Vi povas atingi subreton malantaŭ tunela finpunkto per tri manieroj, kaj unu minuto da faktoj kutime ekskludas du. La faktoj estas, ĉu la serviloj tie devas distingi uzantojn, ĉu iu tie iam vokos al via gamo, kaj kiu rajtas redakti la enkursigilon ĉe la malproksima fino. Respondu tiujn tri kaj la dezajno elektiĝas mem. La resto supozas, ke vi administras la finpunkton kaj rajtas redakti ĝian fajroŝirmilon.
Tri opcioj, kaj kion ĉiu vere ŝanĝas
Prefiksa mapado, DNAT-po-gastiganto kaj voja prefikso ĉiuj movas pakaĵojn inter la samaj du gamoj, sed ili ŝanĝas malsamajn aferojn. Mapado elpensas aliasan gamon kaj reskribas adresojn aritmetike dumfluge. Reguloj po gastiganto ankaŭ reskribas, nur ĉiu celo estas nomata permane. Voja prefikso reskribas nenion: pakaĵoj konservas la realajn adresojn kaj ambaŭ finoj konsentas, kie tiuj adresoj loĝas.
| What the far side needs | Prefix mapping | Per-host DNAT | Routed prefix |
|---|---|---|---|
| Users visible to its logs | Only without source NAT | Same condition | Yes, unchanged |
| To start a connection toward you | No, alias is local | No, same reason | Yes, both ends route |
| To absorb a new host | Yes, arithmetic only | No, one rule per address | Yes, it simply routes |
| To require no config change | Yes, with source NAT | Yes, same condition | No, it needs a route back |
Komencu la eliminan de la malproksima flanko, kie la limigoj estas plej malfacile ŝanĝeblaj. Se servilo tie skribas klientajn adresojn en protokolojn, kontrolas ilin kontraŭ permeslisto aŭ transdonas ilin al alia sistemo, traduki la fonton detruas ĝian solan identigilon. Se la malproksima flanko ankaŭ devas voki, traduko tute ne eblas, ĉar neniu tie scias, ke la aliaso ekzistas. Nur kiam la malproksima flanko simple respondas petojn, la pli malmultekostaj opcioj fariĝas sekuraj.
Prefiksaj paroj, kaj kial la grandecoj devas kongrui
NETMAP estas celo de la nat-tabelo, kiu laboras sur paro da prefiksoj de egala longo. Ĝi havas nenian tabelon po adreso interne: ĝi forprenas la prefikson, konservas la gastigantajn bitojn kaj realigas ilin al la nova prefikso, kaj tial /24 mapiĝas al /24 kaj neniam al /25. La pozicio decidas la direkton: celo-kongruo en PREROUTING reskribas, kien pakaĵo iras, kaj fonto-kongruo en POSTROUTING reskribas, de kie ĝi venis.
Gastiganto ĉe 192.168.2.17 aperas al viaj klientoj kiel 10.50.1.17, kaj la lasta okto ne estas ornama — ĝi estas la sama nombro ĉe ambaŭ flankoj. Aldonu morgaŭ gastiganton ĉe 192.168.2.40 kaj ĝia aliaso estas 10.50.1.40, sen regulo por redakti.
Klientoj ankoraŭ bezonas vojon por la aliasa gamo direktitan al via skatolo, krom se la aliaso falas en subreto, kiun ili jam atingas. La pordego bezonas neniun vojon por la aliaso, ĉar celtraduko kuras en PREROUTING, antaŭ la voja serĉo. Plusendo ankaŭ devas esti ŝaltita, alie la kerno forĵetas la pakaĵon post la reskribo. La tri komandoj sube estas la tuta agordo sur pordego laŭ Debian-stilo kun klientoj sur br0, la aliaso sur 10.50.1.0/24 kaj la tunelo sur tun0.
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A PREROUTING -i br0 -d 10.50.1.0/24 -j NETMAP --to 192.168.2.0/24
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADELa respondo devas mem trovi sian vojon reen
Reskribi la celon nur decidas, kien pakaĵo estos liverita. La servilo ĉe la malproksima flanko ankoraŭ devas respondi adreson, kiun ĝi povas atingi, kaj estas du manieroj tion aranĝi. Traduku la fonton, por ke respondoj revenu al via skatolo, aŭ lasu la fonton trankvila kaj donu al la malproksima flanko vojon por la klienta gamo.
Maskado sur la eliro estas la pli mallonga vojo: unu regulo en POSTROUTING kaj la malproksima flanko vidas vian tunelan adreson, do ĝi bezonas neniun propran vojon. La kosto estas, ke ĉiuj uzantoj kunfandiĝas en unu adreson kaj protokoloj po uzanto ĉesas signifi ion. Lasi la fonton netuŝita konservas tiun informon, sed tiam la malproksima loko devas resendi respondojn por la klienta gamo tra la tunelo. Sur OpenVPN servilo tio estas puŝita push "route 10.50.9.0 255.255.255.0", plus linio route 192.168.2.0 255.255.255.0.
La multekosta fiasko estas fari duonon de ĉiu. Se vi maskas parton de la trafiko dum la malproksima flanko ankaŭ portas returnan vojon por alia trafiko, respondoj alvenas sur interfaco, kie la konektospura rikordo neniam estis vidita. La kliento raportas tempolimon por peto, kiun la servilo protokolis kiel servitan. Ambaŭ direktoj de fluo devas trapasi la saman netfilter-kopion: unu pordego tradukanta, ne du fajroŝirmiloj sinsekve.
conntrack -L -d 10.50.1.17
iptables -t nat -L PREROUTING -v -nLegu la rikordon en ambaŭ direktoj: la originala opo konservas vian aliason ĉe la celo, dum la responda opo portas la realan adreson. Se la responda opo mankas, la revena vojo estas la problemo, ne la regulo. Se la PREROUTING-nombriloj neniam moviĝis, la pakaĵo neniam atingis tiun hokon.
Kolizioj kaj la serĉo, kiu kuras unue
Du malsamaj gamoj povas kolizii, kaj ambaŭ fiaskoj aspektas kiel rompita tunelo, ne kiel malbona regulo. La aliaso, kiun vi elpensas, devas esti neuzata laŭ la tuta vojo, kaj la reala gamo de la malproksima flanko ne devas jam ekzisti en via reto. Duoblaĵo produktas intermitan trafikon al la malĝusta gastiganto, kio estas pli malfacile diagnozebla ol rifuzita konekto. Demandu la vojigan tabelon antaŭ ol aldoni regulon.
Sur la pordego, ip route get 192.168.2.17 devus nomi la tunelan aparaton; loka ponto signifas, ke la malproksima gamo estas ombrata kaj neniu nat-regulo riparos ĝin. Se via propra reto jam uzas 192.168.2.0/24, renumeru la malproksiman lokon anstataŭ staki mapadon sur la kolizion.
Testi ĝin de reala kliento, poste konservi ĝin
Testu de maŝino, kiu vere uzos la aliason, ne de la pordego, ĉar loke generita trafiko neniam trapasas PREROUTING samme. Malfermu konekton al unu aliasita gastiganto kaj observu la nombrilojn kaj la conntrack-rikordon aperi kune, poste fermu ĝin kaj konfirmu, ke la rikordo foriras. Malnova rikordo indikas duonmalfermitan konekton, kio kutime signifas, ke la respondo neniam revenis.
curl -sv http://10.50.1.17/ -o /dev/null
ss -tn dst 10.50.1.17
conntrack -L -d 10.50.1.17Du aŭ tri sukcesaj konektoj pruvas la aritmetikon, sed ili diras nenion pri daŭreco aŭ pri la sekva inĝeniero. Konservu la regulojn tie, kie la startiga procezo legas ilin, kio ĉe Debian kaj Ubuntu signifas iptables-save > /etc/iptables/rules.v4 kun netfilter-persistent ŝaltita. Mapado, kiu malaperas ĉe relanĉo, estas pli malbona ol neniu, ĉar la paneo venas sen lastatempa ŝanĝo por kulpigi.
Lasu noton apud la reguloj: la aliasa gamo, la reala gamo, la kialo de la paro kaj kiu flanko rajtas iniciati. Tiu noto apartigas dezajnon de amaso da reguloj, kiujn neniu kuraĝas forigi. Ĝi ankaŭ solvas la postan demandon, kiam la malproksima loko aldonas gastiganton kaj adreso, kiun neniu agordis, jam respondas. Se la noto diras, ke la malproksima flanko bezonas returnan vojon, la sekva persono scias, ke forigo de la maskada regulo rompas konektecon. Dokumentado estas malmultekosta ĉi tie; retrovari NAT-dependecon je la tria matene ne estas.