OpenVPN-kliento atingas la servilon sed ne la LAN-gastigantojn: kontrol-list

La kliento diras ke ĝi estas konektita, la tunela adreso respondas al ping, kaj nenio en la oficeja LAN respondas. Mi vidas tion post preskaŭ ĉiu klienta ĝisdatigo, kaj la unua instinkto estas malfermi la fajromuron, kio kutime estas la malĝusta paŝo: la tunelo estas en ordo, kaj la rompo estas ĉe unu el tri saltoj, kiujn la pakaĵo devas trapasi. Trairu la vojon en la ordo, en kiu la pakaĵo iras, unue la klienta vojo, poste la plusendado ĉe la servilo, poste la revena vojaĝo, kaj vi trovos la posedanton de la misfunkcio post kelkaj minutoj.

Paŝo unu: observu la enkursigan decidon de la kliento

Antaŭ ol tuŝi la servilon, pruvu ke la kliento sendas la pakaĵon en la tunelon. Demandu la kernon, kiun interfacon ĝi uzus por unu specifa LAN-gastiganto, anstataŭ legi la tutan tabelon:

ip route get 192.168.50.10

Se la respondo nomas vian fizikan adaptilon kaj la oficejan enirejon, neniu ŝanĝo ĉe la servila flanko povas helpi. OpenVPN disdonas vojojn nur kiam la servilo puŝas ilin, do serĉu push "route 192.168.50.0 255.255.255.0" en la servila agordo, kaj poste rekonektu la klienton. Plej multaj klientoj aplikas puŝitajn vojojn ĉe konekto, ne kiam vi reŝargas la profilon.

En Windows la sama demando havas alian komandon. Find-NetRoute -RemoteIPAddress 192.168.50.10 presas la interfacon kaj la sekvan salton, kiujn la stako elektus, kaj route print -4 montras ĉu la puŝita prefikso entute ekzistas.

Paŝo du: konfirmu ke la servilo plusendos la pakaĵon

Se la klienta vojo estas ĝusta, la pakaĵo atingas la servilon, kaj la servilo devas konsenti plusendi ĝin. La kernŝaltilo estas la unua pordego, kaj sysctl net.ipv4.ip_forward devas redoni 1. Agordi ĝin per echo 1 > /proc/sys/net/ipv4/ip_forward funkcias ĝis la sekva restartigo, kaj ĝuste tial la sama plendo revenas semajnojn poste.

Skribu ĝin ie, kio postvivas restartigon:

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

La dua pordego estas la filtra tabelo. Gastiganto kun instalita Docker ofte portas politikon FORWARD je DROP, kaj la tunelo heredas tiun decidon. iptables -L FORWARD -v -n montras kaj la politikon kaj la pakaĵajn nombrilojn; se la politiko estas DROP, la plusendado bezonas eksplicitan permeson por la direkto de la tunelo al la LAN kaj unu por la respondo.

Paŝo tri: sekvu la pakaĵon ĝis la LAN kaj serĉu la respondon

Observu ambaŭ flankojn de la servilo samtempe. Kaptu ĉe la tunelo kaj ĉe la LAN-interfaco, filtritaj al unu kliento kaj unu gastiganto por ke la eligo restu legebla:

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

Peticioj, kiuj aperas ĉe tun0 kaj denove ĉe eth0 kun fonto 10.8.0.x, sekvitaj de silento, signifas ke la pakaĵo alvenis kaj la respondo iris aliloken. La LAN-gastiganto respondas al sia defaŭlta enirejo, tiu enirejo ne havas vojon por la VPN-pool, kaj la respondo mortas ĉe la LAN-vojmontrilo. Pingi la LAN-gastiganton de la servilo pruvas nenion pri tiu vojo, ĉar tiu trafiko neniam transiras la tunelon.

Paŝo kvar: elektu inter traduko kaj revena vojo

Du riparoj fermas la truon, kaj la elekto havas sekvojn preter tio, ĉu ping funkcias. Fonta traduko igas la servilon la ŝajna sendanto:

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

Limigu la regulon al la pool kaj al la LAN-interfaco, poste faru ĝin permanenta, alie la sekva reŝargo de la fajromuro silente forigos vian riparon. La kosto estas identeco: ĉiu kliento aspektas kiel la VPN-servilo en LAN-protokoloj kaj aliraj reguloj, kaj per-client policy becomes guesswork.

Statika vojo por 10.8.0.0/24 ĉe la LAN-vojmontrilo, montranta al la VPN-servilo, tenas la klientajn adresojn videblaj kaj estas la pli bona longtempa respondo kiam tiu vojmontrilo estas via. Multaj ejoj funkciigas ambaŭ dum tempo, NAT por la tuja riparo kaj la vojon post kiam la fajromura politiko estas skribita. Se la servilo estas loko-al-loko samtavolo anstataŭ pool, la servila flanko ankaŭ bezonas iroute por la fora subreto, alie la samtavola vojo ekzistas sed la klienta trafiko neniam estas asociata kun ĝi.

Paŝo kvin: kontrolu el la kliento kaj notu, kio ŝanĝiĝis

Fermu la ciklon el la kliento, ne el la servilo. Konektiĝu al reala servo ĉe la LAN-gastiganto, poste konfirmu ke la tradukaj nombriloj moviĝis per iptables -t nat -L POSTROUTING -v -n, ĉar regulo kun nulo da pakaĵoj estas regulo, kiu neniam kongruis. conntrack -L -s 10.8.0.5 montras la fluon kaj ĝian staton kiam vi bezonas pruvon, ke la revena direkto estas spurata.

Lasu noton en la servila agordo: kiu subreto, kiu interfaco, kiu regulo, kaj ĉu la LAN-vojmontrilo portas vojon reen. La venontan fojon, kiam klienta ĝisdatigo forviŝos puŝitan vojon, tiu noto transformos fajrobrigadan sesion en riparon de unu linio.