Kaugkasutajad ei jõua VPN-jaoturi kaudu teise asukohta

Kaugkasutaja ühendub jaoturiga, jõuab jaoturi enda LAN-i failiserverini ja kõik tundub terve. Siis avab ta peakorteris aadressil 10.20.0.50 asuva jagatud kausta, kuhu jaotur pääseb eraldi asukohtadevahelise tunneliga, ja see aegub. Mõlemad tunnelid on üleval ja mõlemad loendurid kasvavad, seega kumbki tunnel ei ole katki. Jaoturi läbimine on kolm marsruutimisotsust kolmel seadmel ja tunnel kannab ainult neid prefikseid, mille jaoks see ehitati. Siin on järjekord, mida ma kontrollin, ja käsk, mis näitab, kas iga samm peab paika.

Läbikäik nõuab kolme otsingut, mitte ühte tunnelit

Iga seade teeb oma pikima prefiksi vaste ja unustab selle. Sülearvuti peab saatma 10.20.0.50 tunnelisse, mitte oma kohalikku ruuterisse. Jaotur peab võtma paketi, mis saabus kaugjuurdepääsu liidesele, ja andma selle asukohtadevahelisele liidesele. Peakorter peab saatma kasutaja aadressile vastuse tagasi läbi tunneli. Kui ükskõik milline neist kolmest ebaõnnestub, näeb see brauseris ühesugune välja: vaikus.

Seepärast tõestab iga tunneli eraldi testimine nii vähe. Jaoturi LAN-aadressi pingimine harjutab esimest otsust ja jaoturi pingimine peakorterist kolmandat. Paketil, mis ebaõnnestub, on allikaks kasutajate bassein ja sihtkohaks teine asukoht, seega kirjutage need prefiksid kõigepealt üles. Siin on bassein 10.80.0.0/24, jaoturi LAN 10.10.0.0/24 ja peakorter 10.20.0.0/24.

Lükake kaugprefiks kaugkliendile

Ühel OpenVPN kaugjuurdepääsu serveril õpib klient marsruudid ühendamise hetkel. Ilma push-ita saadab jagatud tunneliga klient 10.20.0.50 oma lüüsile ja pakett ei sisene kunagi tunnelisse.

push "route 10.20.0.0 255.255.255.0"

Lükatud marsruut rakendub kliendi ühendamisel, seega võrgus püsiv kasutaja ei näe midagi, kuni ta uuesti ühendub. Kontrollige kliendil: ip route get 10.20.0.50 Linuxis, route print Windowsis. Väljund peaks nimetama tunneli liidest.

Push ei aita jaoturit. See on sõnum kliendile, mitte marsruut serveril ja mitte luba edastada, seega jaotur, millel on täiuslik push-rida, pillab voolu ikkagi üks hüpe hiljem. See on tavaline põhjus, miks inimesed järeldavad, et push ebaõnnestus.

Andke jaoturile tõeline väljundmarsruut

Jaotur vajab peakorteri prefiksi jaoks oma järgmist hüpet. Marsruuditud tunnelil on see tavaline marsruut läbi asukohtadevahelise liidese ja üks käsk näitab nii valitud marsruuti kui ka valitud allikat:

ip route get 10.20.0.50 from 10.80.0.25
sudo ip route add 10.20.0.0/24 via 172.30.0.2 dev s2s0

Kui asukohtadevaheline jalg on ise OpenVPN, võib marsruut elada selles konfiguratsioonis, kus partneri tunneli aadress on lüüs: route 10.20.0.0 255.255.255.0 172.30.0.2. Lüüs ei ole valikuline. Jätke see välja ja järgmine hüpe langeb implementatsiooni vaikeväärtusele, mis erineb ühe partneriga kliendi ja mitme partneriga jaoturi vahel.

Poliitikapõhine IPsec on teistsugune: jaoturi kernel saadab paketi oma tavalisse LAN-lüüsi ja poliitika püüab selle väljumisel kinni, seega tunneli marsruut kas ei tee midagi või suunab liikluse poliitikast mööda. Jälgige ülaltoodud käsus allikat, sest 10.10.0.1 basseini aadressi asemel tähendab, et kernel valis aadressi, mille kaugpool tõrgub. iroute ei ole samuti vastus; see ütleb serverile, milline klient omab oma tunneli taga alamvõrku, mitte kuhu saata liiklust kolmanda asukoha jaoks.

Laiendage kaugpool kasutajate basseinile

Peakorter katab juba jaoturi LAN-i, 10.10.0.0/24. Kasutajate bassein on teine prefiks ja peab olema ka selektorites, muidu ei kata ükski poliitika vastust, mis on adresseeritud aadressile 10.80.0.25. Iga partner nimetab sama prefiksikomplektide paari oma poolelt:

# strongSwan swanctl.conf, on the hub
local_ts  = 10.10.0.0/24, 10.80.0.0/24
remote_ts = 10.20.0.0/24

# on the headquarters peer
local_ts  = 10.20.0.0/24
remote_ts = 10.10.0.0/24, 10.80.0.0/24

Ühe seadme local_ts on teise remote_ts. Kopeerige jaoturi plokk peakorterisse ja paar pöördub ümber, seega child SA ei tõuse kunagi.

Vanem ipsec.conf süntaks kasutab komadega eraldatud leftsubnet. Töötav turvaassotsiatsioon hoiab selektoreid, mille ta läbi rääkis, seega taastage tunnel pärast muudatust. Kell 10:00 muudetud selektor, mida testitakse SA vastu, mis tõusis kell 09:40, ebaõnnestub endiselt, samal ajal kui konfiguratsioonifail näib kogu aeg korrektne.

Seejärel kontrollige viimast hüpet. ip route get 10.80.0.25 kaugses lõpp-punktis peaks osutama tunnelisse. Kui teenus kasutab LAN-ruuterit vaikelüüsina, vajab see ruuter ka tagasiteed, muidu sureb vastus seal. Käsuga tcpdump -ni eth1 host 10.80.0.25 sellel segmendil näete, kas vastus üldse lõpp-punktist lahkus.

Lubage voog jaoturis

Edastamine peab olema lubatud ja tee lubatud. Piirake reeglid kahe prefiksiga, selle asemel et liideste vahel kõike aktsepteerida.

sysctl -w net.ipv4.ip_forward=1
iptables -I FORWARD -i tun0 -o s2s0 -s 10.80.0.0/24 -d 10.20.0.0/24 -j ACCEPT
iptables -I FORWARD -i s2s0 -o tun0 -s 10.20.0.0/24 -d 10.80.0.0/24 -j ACCEPT

Tagasitee filtreerimine on selle kõrval vaikne tõrge: kui kaks jalga on erinevatel liidestel, võib rp_filter=1 vastuse maha visata, samal ajal kui vastuvõtureegli loendur ei liigu kunagi. Võrrelge iptables -vnL FORWARD enne ja pärast katset. Reeglini, mis ei suurene kunagi, ei jõuta, seega vaadake kiht allpool, selle asemel et seda ümber kirjutada.

Kui läbikäiku vajab ainult üks rühm, pange marsruut kliendipõhisesse faili kausta client-config-dir alla, selle asemel et globaalset push-i laiendada. Lähteaadressi NAT jaoturis kõrvaldab ka kaugpoolse tagasitee vajaduse, kuid peidab kasutaja aadressi, seega kaugkoha logid ja aadressipõhised reeglid ei erista enam kasutajaid.

Kontrollige kliendist ja seejärel võtke muudatused tagasi vastupidises järjekorras

Testige TCP-porti, mitte ainult ICMP-d, sest ping võib läbi minna, samal ajal kui teenus jääb blokeerituks. nc -vz 10.20.0.50 445 ja traceroute -n 10.20.0.50 kliendist näitavad, kas teine hüpe on jaoturi tunneli aadress. Jaoturis tcpdump -ni tun0 host 10.20.0.50 ja sama filter asukohtadevahelisel liidesel: päring mõlemal ilma vastuseta kummalgi viib probleemi kaugpoolele.

Seejärel testige midagi, mis peab blokeerituks jääma. Kui vastab ka host, kuhu bassein ei tohiks kunagi jõuda, olete avanud rohkem kui läbikäigu ja peaksite reegleid kitsendama. Jaotur, mis edastab kõik igale harule, läbib esimese testi ja ebaõnnestub teises.

Pidage tagasivõtmisnimekirja, sest muutus neli objekti ja kolme on lihtne unustada: lükatud marsruut, jaoturi marsruut, selektorid ja tulemüürireeglid. Võtke need tagasi vastupidises järjekorras, taastage SA ja laske ühel kasutajal uuesti ühenduda. Osaline tagasivõtmine jätab marsruudi, mis osutab tunnelile, mis enam ei sobi, mida on raskem lugeda kui algset vaikust. OpenVPN 2.6 käsiraamat dokumenteerib push, route ja iroute teie versiooni jaoks.