Kial via LAN ne povas atingi servon ĉe VPN-kliento

VPN-kliento povas gastigi servon, kiun la LAN ne povas malfermi. Kutime mankas la revena vojo: unu itinero, paro da DNAT, aŭ la linio SNAT, kiun neniu aldonas.

Via tunelo estas aktiva, la servo aŭskultas, kaj la ofica LAN ankoraŭ ricevas nenion reen. Neniu rompis la VPN-on. De la flanko de la LAN, la tunela adreso de la tekkomputilo ne ekzistas ĝis io diras al la LAN, kiel atingi ĝin, kaj la respondo devas reveni la saman vojon, kiun iris la peto. Mi vidis homojn tri fojojn rekonstrui tute sanan tunnelon antaŭ ol iu rigardis la revenan vojon.

Ne la tunelo rompiĝis

Ambaŭ finoj sidas sur privataj gamoj, kio estas la normala kazo kaj ne misagordo. Adreso kiel 10.8.0.6 estas reala ene de la tunelo kaj neekzistanta ĉie alie, do la LAN ne havas kialon sendi ion tien. Antaŭ ol tuŝi la enkursigadon, konfirmu, ĉu la servo entute estas atingebla ene de la tunelo: ĉe la kliento ss -ltn montras, ĉu la aŭskultanto ligiĝas al 127.0.0.1, al la LAN-interfaco aŭ al la tunela adreso. Demono ligita nur al loopback respondas al neniu krom si mem, kaj neniu itinero, DNAT aŭ pordea plusendado tion ŝanĝas.

Prokura servilo sur pordo 80 aŭ 443 estas alia ilo kun alia videbleco. Ĝi movas petojn, ne pakaĵojn, do ĝi estas la malĝusta tavolo por kruda datumbaza konekto, kaj ekpreni ĝin estas kiel ĉi tiu problemo finiĝas tri ilojn profunde antaŭ ol iu mezuras ion ajn.

Itinera formo: diru al la LAN, kie estas la aro

Statika itinero sur la LAN-enirejo estas la plej pura respondo, kiam la LAN kaj la tunela aro ne interkovriĝas. Direktu la aron al la maŝino, kiu finas la tunnelon:

ip route add 10.8.0.0/24 via 192.168.1.12
route add -p 10.8.0.0 mask 255.255.255.0 192.168.1.12   # Windows, persistent

Tio riparas nur unu direkton, kaj tial duonfinitaj versioj de ĉi tiu ŝanĝo aspektas kiel progreso. La tunela flanko bezonas la respondan duonon, alie la respondo forlasas la klienton per sia propra defaŭlta itinero kaj mortas survoje:

push "route 192.168.1.0 255.255.255.0"

Por subreto, kiu staras malantaŭ unu kliento anstataŭ malantaŭ la servilo, la servilo bezonas kaj sisteman itineron kaj rikordon iroute en la dosiero de tiu kliento sub client-config-dir. Sen iroute, OpenVPN scias, ke la prefikso ekzistas, kaj tute ne scias, kiu kliento posedas ĝin: pakaĵoj alvenas kaj la demono havas nenion, kun kio kunigi ilin.

Jen la mito, kiun indas nomi. Itinero igas adreson atingebla; ĝi ne igas la kontraŭan flankon pretan respondi. Loko-al-lokaj partneroj aldonas ankoraŭ unu tavolon supre, ĉar la fora enirejo akceptas nur fontojn ene de la prefiksoj de sia politiko, kaj tekkomputilo venanta el hejma aro ne estas ene de ili.

NAT-formo: DNAT enen kaj la linio SNAT, kiun ĉiuj preterlasas

Kiam vi ne povas tuŝi la LAN-enirejon, aŭ volas publikigi precize unu pordon, tradukado sur la VPN-gastiganto funkcias tute sen itinero en la LAN. Publikigu la pordon, plusendu ĝin, kaj traduku la fonton survoje en la tunnelon:

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8080 -j DNAT --to-destination 10.8.0.6:3000
iptables -A FORWARD -i eth0 -o tun0 -p tcp -d 10.8.0.6 --dport 3000 -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -d 10.8.0.6 -p tcp --dport 3000 -j SNAT --to-source 10.8.0.1

La tria linio estas la perdita. Preterlasu ĝin kaj la kliento vidas la originan LAN-adreson kiel fonton, respondas per sia propra defaŭlta itinero, kaj tiu respondo iras en la tunnelon anstataŭ reen al la LAN. Ĉu la konekto postvivos, tiam dependas de enkursigado, kiun vi neniam planis. Kun SNAT la kliento vidas la tunelan adreson de la servilo, do la respondo sekvas la tunnelon reen al la sola gastiganto, kiu povas malfari la tradukon.

Konsumanta firmaro uzas proprajn ĉenajn nomojn kaj ne generas tiun tradukon por vi. Ĉe Tomato, envenanta regulo alteriĝas en WANPREROUTING kaj poste en filtran ĉenon kiel wanin, kaj regularo, kiu aspektas kompleta, ankoraŭ bezonas permanan linion POSTROUTING. Tio ne estas firmara cimo; ĝi estas regularo skribita nur por envenanta trafiko.

Kial ĝustaspekta regulo tamen faligas la pakaĵon

Plej multaj el tiuj fiaskoj ne estas en la regulo, kiun vi fiksrigardas. Kontrolu kvar aferojn laŭ ĉi tiu ordo kaj haltu ĉe la unua, kiu ne validas:

  • Ĉena ordo. iptables -I enmetas supre kaj -A aldonas malsupre, do pli frua permesa aŭ bloka regulo decidas unue.
  • Malĝusta ĉeno. Trafiko adresita al la enkursigilo mem trapasas INPUT, kaj plusendita trafiko neniam tuŝas ĝin. Publikigi unu servon povas postuli regulojn en ambaŭ.
  • Direktaj flagoj. -i tun0 kongruas trafikon alvenantan de klientoj kaj -o tun0 trafikon forirantan al ili. REJECT kun la malĝusta flago blokas ion, kion vi ne intencis.
  • Fonta limigo. Plusendado, kiu akceptas unu klientan adreson, funkcias de tiu kliento kaj faligas ĉiun alian fonton sen vorto.

Regulo kun nula pakaĵa nombrilo tute ne estas sur la vojo, kaj legi la nombrilojn estas la plej rapida maniero apartigi malĝustan-ĉenan problemon de malĝustan-regulan problemo.

La loka plusendado, kiam nenio en la LAN povas ŝanĝiĝi

Loka SSH-plusendado preterlasas la tutan demandon. Ĝi bezonas neniun itineron en la LAN, neniun kunlaboron de la klienta fajroŝirmilo, kaj neniun pordon publikigitan ie ajn:

ssh -N -f -L 3000:10.8.0.6:3000 user@vpn-host

La servo tiam aperas ĉe localhost:3000 de la maŝino, kiu funkciigas la tunnelon, kaj nenie alie. Tio estas la limo: unu laborejo, unu pordo, kaj la plusendado mortas kun la seanco, se io ne restartigas ĝin. Por administranto, kiu kontrolas testan datumbazon, ĝi estas la ĝusta ilo. Por fotilo aŭ skanilo, kiun aliaj homoj devas atingi, ĝi ne estas, ĉar ĉiu uzanto bezonus sian propran plusendadon.

Kontrolu ambaŭ direktojn antaŭ ol aldoni alian regulon

Tradukado lasas spurojn, kaj legi ilin superas divenadon. Ĉe la VPN-gastiganto, conntrack -L montras, ĉu la traduko entute okazis, iptables -t nat -L -n -v montras, ĉu la nombriloj moviĝis, kaj tcpdump -ni any port 3000 montras, kiu fonta adreso fakte alvenis. Ĉe la kliento, ss -ltn konfirmas, ke la aŭskultanto estas sur adreso, kiun la tunelo povas atingi.

Poste elektu la formon, kiun vi konservas. Unu publikigita pordo, itinero por la tuta aro kaj plusendado por unu sola administranto estas tri malsamaj sindevontigoj, kaj miksi ilin estas kiel funkcianta agordo fariĝas tiu, kiun neniu povas klarigi post ses monatoj. Skribu, kiu adreso estas atingebla de kie, kaj la sekva persono, kiu sencimigos ĉi tion, komencos ĉe la respondo anstataŭ ĉe la tunelo.

Rilataj artikoloj