„OpenVPN“ klientas pasiekia serverį, bet ne LAN kompiuterius: kontrolinis sąrašas

Klientas praneša, kad prisijungta, tunelio adresas atsako į ping, o biuro LAN tinkle niekas neatsako. Tai matau po beveik kiekvieno kliento atnaujinimo, ir pirmoji nuojauta yra atidaryti ugniasienę, o tai dažniausiai neteisingas žingsnis: tunelis tvarkingas, o trūkis yra viename iš trijų šuolių, kuriuos paketas turi pereiti. Eikite keliu ta tvarka, kuria eina paketas, pirmiausia kliento maršrutas, tada serverio perdavimas, tada kelionė atgal, ir per porą minučių rasite gedimo šeimininką.

Pirmas žingsnis: stebėkite kliento maršrutizavimo sprendimą

Prieš liesdami serverį, įrodykite, kad klientas siunčia paketą į tunelį. Paklauskite branduolio, kokią sąsają jis naudotų vienam konkrečiam LAN kompiuteriui, o ne skaitykite visą lentelę:

ip route get 192.168.50.10

Jei atsakyme nurodomas jūsų fizinis adapteris ir biuro šliuzas, joks pakeitimas serverio pusėje nepadės. OpenVPN maršrutus dalija tik tada, kai serveris juos stumia, todėl ieškokite push "route 192.168.50.0 255.255.255.0" serverio konfigūracijoje ir po to iš naujo prijunkite klientą. Dauguma klientų stumiamus maršrutus pritaiko prisijungdami, o ne perkraudami profilį.

„Windows“ sistemoje tas pats klausimas turi kitą komandą. Find-NetRoute -RemoteIPAddress 192.168.50.10 išspausdina sąsają ir kitą šuolį, kurį pasirinktų dėklas, o route print -4 parodo, ar stumiamas priešdėlis apskritai egzistuoja.

Antras žingsnis: patvirtinkite, kad serveris persiųs paketą

Jei kliento maršrutas teisingas, paketas pasiekia serverį, ir serveris turi sutikti jį persiųsti. Branduolio jungiklis yra pirmi vartai, ir sysctl net.ipv4.ip_forward turi grąžinti 1. Nustatymas su echo 1 > /proc/sys/net/ipv4/ip_forward veikia iki kito perkrovimo, ir būtent todėl ta pati skunda grįžta po kelių savaičių.

Užrašykite tai ten, kur išlieka po perkrovimo:

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

Antri vartai yra filtro lentelė. Kompiuteryje su įdiegtu Docker dažnai galioja FORWARD taisyklė DROP, ir tunelis paveldi tą sprendimą. iptables -L FORWARD -v -n rodo ir taisyklę, ir paketų skaitiklius; jei taisyklė yra DROP, persiuntimui reikia aiškaus leidimo krypčiai iš tunelio į LAN ir dar vieno atsakymui.

Trečias žingsnis: sekite paketą į LAN ir ieškokite atsakymo

Stebėkite abi serverio puses vienu metu. Fiksuokite tunele ir LAN sąsajoje, filtruodami vienam klientui ir vienam kompiuteriui, kad išvestis liktų įskaitoma:

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

Užklausos, kurios pasirodo tun0 ir vėl eth0 su šaltiniu 10.8.0.x, o po jų – tyla, reiškia, kad paketas atėjo, o atsakymas nuėjo kitur. LAN kompiuteris atsako savo numatytajam šliuzui, tas šliuzas neturi maršruto į VPN telkinį, ir atsakymas žūna LAN maršrutizatoriuje. Pinginti LAN kompiuterį iš serverio nieko neįrodo apie šį kelią, nes tas srautas niekada nekerta tunelio.

Ketvirtas žingsnis: rinkitės tarp vertimo ir grįžimo maršruto

Du taisymai uždaro skylę, ir pasirinkimas turi pasekmių, viršijančių tai, ar veikia ping. Šaltinio vertimas padaro serverį regimu siuntėju:

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

Apribokite taisyklę telkiniu ir LAN sąsaja, tada padarykite ją nuolatinę, kitaip kitas ugniasienės perkrovimas tyliai pašalins jūsų pataisą. Kaina yra tapatybė: kiekvienas klientas LAN žurnaluose ir prieigos taisyklėse atrodo kaip VPN serveris, ir per-client policy becomes guesswork.

Statinis maršrutas 10.8.0.0/24 tinklui LAN maršrutizatoriuje, nukreiptas į VPN serverį, išlaiko klientų adresus matomus ir yra geresnis ilgalaikis atsakymas, kai tas maršrutizatorius jūsų. Daugelis vietų kurį laiką naudoja abu, NAT skubiam taisymui ir maršrutą, kai ugniasienės politika jau parašyta. Jei serveris yra site-to-site partneris, o ne telkinys, serverio pusei taip pat reikia iroute nuotoliniam potinkliui, kitaip partnerio maršrutas egzistuoja, bet klientų srautas niekada su juo nesusiejamas.

Penktas žingsnis: patikrinkite iš kliento ir užrašykite, kas pasikeitė

Uždarykite ciklą iš kliento, o ne iš serverio. Prisijunkite prie tikros paslaugos LAN kompiuteryje, tada patvirtinkite, kad vertimo skaitikliai pajudėjo su iptables -t nat -L POSTROUTING -v -n, nes taisyklė be paketų yra taisyklė, kuri niekada nesutapo. conntrack -L -s 10.8.0.5 parodo srautą ir jo būseną, kai reikia įrodymo, kad grįžimo kryptis stebima.

Palikite pastabą serverio konfigūracijoje: kuris potinklis, kuri sąsaja, kuri taisyklė ir ar LAN maršrutizatorius turi grįžimo maršrutą. Kitą kartą, kai kliento atnaujinimas ištrins stumiamą maršrutą, ta pastaba paverčia gaisro gesinimo sesiją vienos eilutės pataisa.