OpenVPN-i klient jõuab serverini, aga mitte LAN-i hostideni: kontrollnimekiri

Klient teatab, et on ühendatud, tunneli aadress vastab pingile ja miski kontori LAN-is ei reageeri. Näen seda peaaegu iga kliendi uuenduse järel ja esimene instinkt on tulemüür avada, mis on tavaliselt vale samm: tunnel on korras ja katkestus on ühes kolmest hüppest, mille pakett peab läbima. Käi tee läbi selles järjekorras, nagu pakett selle läbib, kõigepealt kliendi marsruut, siis serveri edasisaatmine, siis tagasisõit, ja leiad rikke omaniku paari minutiga.

Esimene samm: jälgi kliendi marsruudivalikut

Enne kui serverit puutud, tõesta, et klient saadab paketi tunnelisse. Küsi kernelilt, millist liidest see ühe konkreetse LAN-i hosti jaoks kasutaks, selle asemel et lugeda tervet tabelit:

ip route get 192.168.50.10

Kui vastus nimetab sinu füüsilist adapterit ja kontori lüüsi, ei aita ükski muudatus serveri poolel. OpenVPN jagab marsruute ainult siis, kui server need läbi surub, seega otsi serveri konfiguratsioonist push "route 192.168.50.0 255.255.255.0" ja ühenda klient seejärel uuesti. Enamik kliente rakendab läbi surutud marsruute ühendamise hetkel, mitte profiili uuesti laadimisel.

Windowsis on samal küsimusel teine käsk. Find-NetRoute -RemoteIPAddress 192.168.50.10 trükib liidese ja järgmise hüppe, mille pinu valiks, ning route print -4 näitab, kas läbi surutud prefiks üldse olemas on.

Teine samm: kinnita, et server paketi edasi saadab

Kui kliendi marsruut on õige, jõuab pakett serverini ja server peab nõustuma seda edasi saatma. Kerneli lüliti on esimene värav ja sysctl net.ipv4.ip_forward peab tagastama 1. Selle seadmine käsuga echo 1 > /proc/sys/net/ipv4/ip_forward töötab kuni järgmise taaskäivituseni ja täpselt seetõttu tuleb sama kaebus nädalaid hiljem tagasi.

Kirjuta see kuhugi, mis elab taaskäivituse üle:

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

Teine värav on filtrite tabel. Dockeriga hostil on sageli FORWARD-poliitika DROP ja tunnel pärib selle otsuse. iptables -L FORWARD -v -n näitab nii poliitikat kui ka paketilugejaid; kui poliitika on DROP, vajab edasisaatmine selgesõnalist luba suunale tunnelist LAN-i ja ühte vastusele.

Kolmas samm: jälgi paketti LAN-i ja otsi vastust

Jälgi serveri mõlemat poolt korraga. Püüa liiklust tunnelis ja LAN-liidesel, filtreerituna ühele kliendile ja ühele hostile, et väljund jääks loetavaks:

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

Päringud, mis ilmuvad tun0-l ja uuesti eth0-l allikaga 10.8.0.x, millele järgneb vaikus, tähendavad, et pakett saabus ja vastus läks mujale. LAN-i host vastab oma vaikelüüsile, sellel lüüsil pole VPN-i pooli jaoks marsruuti ja vastus sureb LAN-i ruuteril. LAN-i hosti pingimine serverist ei tõesta selle tee kohta midagi, sest see liiklus ei ületa kunagi tunnelit.

Neljas samm: vali tõlke ja tagasitee vahel

Kaks parandust sulgevad augu ja valikul on tagajärjed kaugemale sellest, kas ping töötab. Allika tõlkimine teeb serverist näilise saatja:

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

Piira reegel pooli ja LAN-liidesega, seejärel tee see püsivaks, muidu eemaldab järgmine tulemüüri uuestilaadimine sinu paranduse vaikselt. Hind on identiteet: iga klient näeb LAN-i logides ja juurdepääsureeglites välja nagu VPN-i server, ja per-client policy becomes guesswork.

Staatiline marsruut 10.8.0.0/24 jaoks LAN-i ruuteril, mis osutab VPN-i serverile, hoiab kliendi aadressid nähtavad ja on parem pikaajaline vastus, kui see ruuter on sinu. Paljud kohad ajavad mõnda aega mõlemat, NAT-i koheseks paranduseks ja marsruudi, kui tulemüüri poliitika on kirjas. Kui server on saidi-saidi partner, mitte pool, vajab serveri pool ka iroute kaugema alavõrgu jaoks, muidu partneri marsruut on olemas, aga kliendi liiklus ei seostu sellega kunagi.

Viies samm: kontrolli kliendist ja pane kirja, mis muutus

Sulge ring kliendist, mitte serverist. Ühendu LAN-i hosti reaalse teenusega, seejärel kinnita, et tõlkeloendurid liikusid iptables -t nat -L POSTROUTING -v -n abil, sest null paketiga reegel on reegel, mis ei sobitunud kunagi. conntrack -L -s 10.8.0.5 näitab voogu ja selle olekut, kui vajad tõestust, et tagasisuund on jälgitud.

Jäta serveri konfiguratsiooni märkus: milline alavõrk, milline liides, milline reegel ja kas LAN-i ruuteril on tagasitee. Järgmine kord, kui kliendi uuendus läbi surutud marsruudi kustutab, muudab see märkus tulekahju kustutamise sessiooni üherealiseks paranduseks.