OpenVPN-biðlari nær þjóninum en ekki LAN-hýslunum: gátlisti

Biðlarinn segist tengdur, gönguheimilið svarar pingi og ekkert á skrifstofu-LANinu svarar. Ég sé þetta eftir nánast hverja biðlarauppfærslu, og fyrsta hvatningin er að opna eldvegginn, sem er venjulega rangt skref: göngin eru í lagi og brotið er á einni af þremur hoppum sem pakkinn verður að fara um. Gakktu leiðina í sömu röð og pakkinn fer, fyrst leið biðlarans, svo framsending þjónsins, svo heimferðin, og þú finnur eiganda bilunarinnar á nokkrum mínútum.

Fyrsta skref: fylgstu með leiðarákvörðun biðlarans

Áður en þú snertir þjóninn skaltu sanna að biðlarinn sendi pakkann inn í göngin. Spurðu kjarnann hvaða tengi hann myndi nota fyrir eina tiltekna LAN-hýslu, í stað þess að lesa alla töfluna:

ip route get 192.168.50.10

Ef svarið nefnir eðlisfræðilega millistykkið þitt og gátt skrifstofunnar getur engin breyting á þjónshlið hjálpað. OpenVPN úthlutar leiðum aðeins þegar þjónninn ýtir þeim, svo leitaðu að push "route 192.168.50.0 255.255.255.0" í stillingum þjónsins og tengdu biðlarann aftur eftir það. Flestir biðlarar beita ýttum leiðum við tengingu, ekki þegar þú hleður sniðinu aftur.

Í Windows hefur sama spurning aðra skipun. Find-NetRoute -RemoteIPAddress 192.168.50.10 prentar tengið og næsta hopp sem staflinn myndi velja, og route print -4 sýnir hvort ýtta forskeytið sé yfirhöfuð til.

Annað skref: staðfestu að þjónninn muni framsenda pakkann

Ef leið biðlarans er rétt nær pakkinn þjóninum og þjónninn verður að samþykkja að framsenda hann. Kjarnarofinn er fyrsta hliðið og sysctl net.ipv4.ip_forward verður að skila 1. Að stilla hann með echo 1 > /proc/sys/net/ipv4/ip_forward virkar þar til næsta endurræsing, og það er einmitt ástæðan fyrir því að sama kvörtunin kemur aftur vikum síðar.

Skrifaðu það niður þar sem það lifir endurræsingu af:

echo 'net.ipv4.ip_forward = 1' > /etc/sysctl.d/99-openvpn-forward.conf
sysctl --system

Annað hliðið er síutóflan. Hýsla með Docker uppsettu er oft með FORWARD-stefnu DROP og göngin erfa þá ákvörðun. iptables -L FORWARD -v -n sýnir bæði stefnuna og pakkatalninguna; ef stefnan er DROP þarf framsendingin skýrt leyfi fyrir stefnuna frá göngunum til LANsins og eitt fyrir svarið.

Þriðja skref: fylgdu pakkanum út á LANið og leitaðu að svarinu

Fylgstu með báðum hliðum þjónsins samtímis. Taktu upp á göngunum og á LAN-tenginu, siað niður á einn biðlara og eina hýslu svo úttakið haldist læsilegt:

tcpdump -ni tun0 host 192.168.50.10
tcpdump -ni eth0 host 192.168.50.10

Beiðnir sem birtast á tun0 og aftur á eth0 með uppruna 10.8.0.x, og þögn tekur við, þýða að pakkinn kom og svarið fór annað. LAN-hýslan svarar sjálfgefinni gátt sinni, sú gátt hefur enga leið fyrir VPN-safnið og svarið deyr á LAN-beininum. Að pinga LAN-hýsluna frá þjóninum sannar ekkert um þessa leið, því sú umferð fer aldrei um göngin.

Fjórða skref: veldu á milli þýðingar og bakleiðar

Tvær viðgerðir loka holunni og valinu fylgja afleiðingar umfram það hvort ping virkar. Upprunnaþýðing gerir þjóninn að sýnilegum sendanda:

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Takmarkaðu regluna við safnið og LAN-tengið og gerðu hana þá varanlega, annars fjarlægir næsta eldveggjahleðsla viðgerðina þína hljóðlega. Kostnaðurinn er sjálfsmynd: hver biðlari lítur út eins og VPN-þjónninn í LAN-skrám og aðgangsreglum, og per-client policy becomes guesswork.

Föst leið fyrir 10.8.0.0/24 á LAN-beininum, sem vísar á VPN-þjóninn, heldur biðlaraföngum sýnilegum og er betra langtímasvar þegar sá beinir er þinn. Margir staðir keyra bæði um tíma, NAT fyrir tafarlausa viðgerð og leiðina þegar eldveggsstefnan er skrifuð. Ef þjónninn er stað-til-staðar jafningi en ekki safn þarf þjónshliðin líka iroute fyrir fjarlæga undirnetið, annars er jafningjaleiðin til en biðlaraumferð er aldrei tengd henni.

Fimmta skref: sannprófaðu frá biðlaranum og skráðu hvað breyttist

Lokaðu lykkjunni frá biðlaranum, ekki þjóninum. Tenging við raunverulega þjónustu á LAN-hýslunni, staðfestu svo að þýðingatalningarnar hafi hreyfst með iptables -t nat -L POSTROUTING -v -n, því regla án pakka er regla sem passaði aldrei. conntrack -L -s 10.8.0.5 sýnir flæðið og ástand þess þegar þú þarft sönnun fyrir því að bakstefnan sé rakin.

Skildu eftir athugasemd í stillingum þjónsins: hvaða undirnet, hvaða tengi, hvaða regla og hvort LAN-beinirinn beri bakleið. Þegar biðlarauppfærsla hreinsar ýtta leið næst breytir sú athugasemd slökkvistarf í viðgerð á einni línu.