Ĉu vi uzu SNAT por pordoadapto en VPN-subreton?

Plusendi pordon al gastiganto, kiu staras malantaŭ la propra VPN-kliento de la enkursigilo, malsukcesas tiel, ke ĝi aspektas kiel fajroŝirma problemo, ĉar la peto klare alvenas. La servo registras konekton, la kliento atendas, kaj nenio revenas. La celloka tradukado faris sian laboron; la revena paketo estas la parto, kiu mankas. Unu selekta fonta-NAT-regulo sur la enkursigilo riparas ĝin, kaj la interesa parto estas decidi, kiom mallarĝa tiu regulo povas esti.

Kial la respondo prenas alian vojon

Pordoadapto reskribas, kien paketo iras, neniam de kie ĝi venis. La adreso de la interreta kliento restas en la fonta kampo la tutan vojon tra la tunelo, do la fora servo vidas fremdulon kaj respondas laŭ la sola maniero, kiun ĝi konas: tra sia propra implicita pordego. Tiu pordego estas la VPN-koncentrilo ĉe la malproksima flanko, kiu havas neniun itineron reen al arbitra publika adreso.

Rigardu kaptaĵon sur la tunela interfaco kaj la malsimetrio estas evidenta: petitaj paketoj eksteren, nenio enen. La plusenda ĉeno permesis la fluon kaj la tunelo portis ĝin, do la forĵeto okazas post kiam la fora gastiganto jam elektis revenan vojon.

Fonta regulo sufiĉe mallarĝa por fidi

Faru la enkursigilon la fonto, al kiu la fora gastiganto respondas. En ĉi tiu aranĝo la WAN-adreso estas 203.0.113.24, la LAN estas 192.168.88.0/24, la tunela adreso de la enkursigilo estas 172.20.5.1, kaj la servo respondas ĉe 172.20.5.40:8443. La suba regulo kongruas kun la paketo post celloka tradukado, tial ĝi nomas la tradukitan adreson anstataŭ la publikan. Nenio en ĝi dependas de la adreso de la kliento, kaj ĝuste tio estas la punkto.

iptables -t nat -A POSTROUTING -o tun0 -p tcp -d 172.20.5.40 --dport 8443 -j SNAT --to-source 172.20.5.1

Ĉiu kongruo en tiu linio ekzistas por teni la reskribadon loka al unu servo sur unu tunelo. Forigu la interfacon aŭ la pordon kaj vi reskribas pli da trafiko ol la problemo postulas, kaj tiel celita riparo fariĝas mistero por la sekva persono.

Kiam ĝenerala maskado estas la honesta elekto

Se la enkursigilo plusendas multajn servojn en la saman VPN-subreton, regulo por servo fariĝas listo, kiun neniu prizorgas. Maski ĉion, kio forlasas la tunelan interfacon, estas pli simpla kaj antaŭvidebla, kontraŭ la kosto kaŝi la originalan klienton de ĉiu gastiganto ĉe la malproksima flanko. Elektu ĝin kiam la protokoloj tie ne estas uzataj por atribuo; konservu la mallarĝan regulon kiam ili estas.

La du opcioj ankaŭ malsukcesas malsame. Mankanta mallarĝa regulo rompas unu servon; larĝa maskado, kiu kongruas kun tro multe, povas silente reskribi trafikon, kiu jam funkciis, inkluzive la proprajn elirajn konektojn de la enkursigilo.

Kontrolu la kalkulilojn antaŭ ol publikigi

Reguloj, kiuj neniam kongruas, aspektas identaj al reguloj, kiuj funkcias, ĝis vi nombras paketojn. Relegu la tabelon kun bajtaj kalkuliloj antaŭ ol iu ajn kliento konektiĝu, poste konektiĝu el reto, kiu ne estas la LAN, kaj relegu ĝin. Du legadoj estas tio, kio transformas konjekton en fakton. Publikigu la plusendon nur post kiam la dua moviĝas.

iptables -t nat -L POSTROUTING -v -n --line-numbers

Nula kalkulilo sur la fonta regulo post reala konekto signifas, ke la kongruo estas malĝusta, kutime ĉar la celo aŭ la pordo ne kongruas kun la paketo post tradukado. Se la kalkulilo supreniras sed la kliento ankoraŭ tempas for, la revena vojo estas riparita kaj io alia faligas la respondon, do rigardu poste la plusendan politikon ĉe la malproksima flanko. Harpingla aliro de ene de la LAN estas aparta problemo kaj bezonas sian propran regulon, ne pli larĝan version de ĉi tiu.