Af hverju LAN-ið þitt nær ekki þjónustu á VPN-biðlara

Göngin þín eru uppi, þjónustan hlustar, og skrifstofu-LAN-ið fær samt ekkert til baka. Enginn braut VPN-ið. Frá LAN-inu séð er göngufang biðlarans ekki til fyrr en eitthvað segir LAN-inu hvernig á að ná í það, og svarið verður að koma til baka sömu leið og beiðnin fór út. Ég hef séð fólk endurbyggja fullkomlega heil göng þrisvar sinnum áður en einhver leit á bakleiðina.

Það er ekki göngin sem bilaði

Báðir endar sitja á einkasviðum, sem er eðlilegt og ekki rangt stilling. Fang eins og 10.8.0.6 er raunverulegt inni í göngunum og er hvergi annars staðar, svo LAN-ið hefur enga ástæðu til að senda neitt þangað. Áður en þú snertir leiðarstillingar skaltu staðfesta að þjónustan sé yfirhöfuð aðgengileg inni í göngunum: á biðlaranum sýnir ss -ltn hvort hlustandinn bindist við 127.0.0.1, LAN-viðmótið eða göngufang. Púki sem er aðeins bundinn við loopback svarar engum nema sjálfum sér, og engin leið, DNAT eða framsending portanna breytir því.

Proxy á porti 80 eða 443 er annað tól með aðra sýnileika. Það færir beiðnir, ekki pakka, svo það er rangt lag fyrir hráa gagnagrunnstengingu, og að grípa til þess er hvernig þetta vandamál endar þremur tólum dýpra áður en einhver mælir nokkuð.

Lögun leiðar: segðu LAN-inu hvar safnið er

Stök leið á LAN-gáttinni er hreinasta svarið þegar LAN-ið og gongusafnið skarast ekki. Beindu safninu að vélinni sem lýkur göngunum:

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

Það lagar aðeins eina átt, og þess vegna líta hálfkláruðar útgáfur af þessari breytingu út eins og framfarir. Gönguhliðin þarf samsvarandi helming, annars yfirgefur svarið biðlarann um sjálfgefna leið sína og deyr á leiðinni:

push "route 192.168.1.0 255.255.255.0"

Fyrir undirnet sem liggur bak við einn biðlara í staðinn fyrir bak við þjóninn þarf þjóninn bæði kerfisleið og iroute-færslu í skrá þess biðlara undir client-config-dir. Án iroute veit OpenVPN að forskeytið er til og hefur ekki hugmynd um hvaða biðlari á það: pakkar berast og púkinn hefur ekkert til að para þá við.

Hér er goðsögnin sem á skilið nafn. Leið gerir fang aðgengilegt; hún gerir hinum megin ekki fúsan til að svara. Síðu-til-síðu jafningjar bæta annarri lag á toppinn, því fjarlæga gáttin tekur aðeins við uppruna innan forskeytanna í stefnu sinni, og fartölva sem kemur úr heimasafni er ekki innan þeirra.

Lögun NAT: DNAT inn, og SNAT-línan sem allir sleppa

Þegar þú getur ekki snert LAN-gáttina, eða vilt birta nákvæmlega eitt port, virkar þýðing á VPN-hýsilnum án nokkurrar leiðar á LAN-inu. Birtu portið, framsendu það og þýddu upprunann á leiðinni inn í göngin:

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

Þriðja línan er sú sem hverfur. Slepptu henni og biðlarinn sér upprunalega LAN-fangið sem uppruna, svarar um sína eigin sjálfgefnu leið, og það svar fer inn í göngin í stað þess að fara til baka til LAN-sins. Hvort tengingin lifir af veltur þá á leiðarstillingum sem þú skipulagðir aldrei. Með SNAT sér biðlarinn göngufang þjónsins, svo svarið fylgir göngunum til baka til hýsilsins sem eina getur afturkallað þýðinguna.

Neytendastýrikerfi nota sín eigin keðjuheiti og búa ekki til þá þýðingu fyrir þig. Á Tomato lendir innkomandi regla í WANPREROUTING og svo í síukeðju eins og wanin, og reglusett sem lítur út fyrir að vera fullkomið þarf samt handvirka POSTROUTING-línu. Það er ekki villa í stýrikerfinu; það er reglusett skrifað aðeins fyrir innkomandi umferð.

Af hverju rétt útlitandi regla sleppir pakkanum samt

Flest þessara mistaka eru ekki í reglunni sem þú starir á. Athugaðu fjóra hluti í þessari röð og stöðvaðu við þann fyrsta sem stendur ekki:

• Röð keðja. iptables -I setur inn efst og -A bætir við neðst, svo fyrri leyfandi eða blokkkandi regla ræður fyrst.
• Röng keðja. Umferð sem er beint að leiðaranum sjálfum fer í gegnum INPUT, og framsend umferð snertir hana aldrei. Að birta eina þjónustu getur þurft reglur í báðum.
• Stefnumerki. -i tun0 passar við umferð sem kemur frá biðlurum og -o tun0 umferð sem fer til þeirra. REJECT með röngu merki blokkar eitthvað sem þú ætlaðir ekki.
• Upprunatakmörkun. Framsending sem tekur við einu biðlarafangi virkar frá þeim biðlara og sleppir hverjum öðrum uppruna án orðs.

Regla með núll pakkatalningu er alls ekki á leiðinni, og að lesa teljarana er fljótlegasta leiðin til að greina vandamál rangrar keðju frá vandamáli rangrar reglu.

Staðbundin framsending, þegar ekkert á LAN-inu getur breyst

Staðbundin SSH-framsending fer fram hjá allri spurningunni. Hún þarf enga leið á LAN-inu, enga samvinnu frá eldvegg biðlarans og ekkert port sem er birt hvar sem er:

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

Þjónustan birtist þá á localhost:3000 vélarinnar sem heldur göngunum, og hvergi annars staðar. Það er mörkin: ein vinnustöð, eitt port, og framsendingin deyr með lotunni nema eitthvað endurræsi hana. Fyrir stjórnanda sem athugar sviðsettan gagnagrunn er það rétta tólið. Fyrir myndavél eða skanna sem aðrir þurfa að ná í er það það ekki, því hver notandi þyrfti sína eigin framsendingu.

Staðfestu báðar áttir áður en þú bætir við annarri reglu

Þýðing skilur eftir sig spor, og að lesa þau er betra en að giska. Á VPN-hýsilnum sýnir conntrack -L hvort þýðingin átti sér stað yfirhöfuð, iptables -t nat -L -n -v sýnir hvort teljararnir hreyfðust, og tcpdump -ni any port 3000 sýnir hvaða upprunafang barst í raun. Á biðlaranum staðfestir ss -ltn að hlustandinn sé á fangi sem göngin ná í.

Veldu svo þá lögun sem þú heldur. Eitt birt port, leið fyrir allt safnið og framsending fyrir einn stjórnanda eru þrjár ólíkar skuldbindingar, og að blanda þeim er hvernig virk uppsetning verður sú sem enginn getur útskýrt hálfu ári seinna. Skrifaðu niður hvaða fang er aðgengilegt hvaðan, og næsta manneskja sem kembir þetta byrjar á svarinu í stað göngunnar.