Nuotoliniai naudotojai nepasiekia antrosios vietos per VPN koncentratorių

Nuotolinis naudotojas prisijungia prie koncentratoriaus, pasiekia failų serverį pačiame koncentratoriaus LAN tinkle, ir viskas atrodo sveika. Tada jis atidaro bendrinamą aplanką adresu 10.20.0.50 būstinėje, kurį koncentratorius pasiekia per atskirą tunelį tarp vietų, ir laikas baigiasi. Abu tuneliai veikia ir abu skaitikliai didėja, taigi nė vienas tunelis nesugadintas. Perėjimas per koncentratorių yra trys maršrutizavimo sprendimai trijuose įrenginiuose, ir tunelis perduoda tik tuos prefiksus, kuriems buvo pastatytas. Štai tvarka, kurią tikrinu, ir komanda, kuri parodo, ar kiekvienas žingsnis teisingas.

Tranzitas reikalauja trijų paieškų, o ne vieno tunelio

Kiekvienas įrenginys atlieka savo ilgiausio prefikso atitikimą ir jį pamiršta. Nešiojamasis kompiuteris turi siųsti 10.20.0.50 į tunelį, o ne savo vietiniam maršrutizatoriui. Koncentratorius turi paimti paketą, atėjusį į nuotolinės prieigos sąsają, ir perduoti jį sąsajai tarp vietų. Būstinė turi siųsti atsakymą naudotojo adresu atgal per tunelį. Jei nepavyksta bet kuris iš trijų, naršyklėje tai atrodo vienodai: tyla.

Štai kodėl kiekvieno tunelio atskiras testavimas įrodo taip mažai. Koncentratoriaus LAN adreso pingavimas lavina pirmąjį sprendimą, o koncentratoriaus pingavimas iš būstinės – trečiąjį. Nepavykusio paketo šaltinis yra naudotojų telkinys, o paskirties vieta – antroji vieta, todėl pirmiausia užsirašykite tuos prefiksus. Čia telkinys yra 10.80.0.0/24, koncentratoriaus LAN – 10.10.0.0/24, o būstinė – 10.20.0.0/24.

Stumkite tolimą prefiksą tolimajam klientui

OpenVPN nuotolinės prieigos serveryje klientas maršrutus sužino prisijungdamas. Be push, klientas su padalintu tuneliu siunčia 10.20.0.50 savo šliuzui ir paketas niekada nepatenka į tunelį.

push "route 10.20.0.0 255.255.255.0"

Stumiamas maršrutas įsigalioja, kai klientas prisijungia, todėl naudotojas, kuris lieka prisijungęs, nieko nemato, kol neprisijungia iš naujo. Patikrinkite kliente: ip route get 10.20.0.50 Linux sistemoje, route print Windows sistemoje. Išvestis turėtų nurodyti tunelio sąsają.

Push nepadeda koncentratoriui. Tai pranešimas klientui, o ne maršrutas serveryje ir ne leidimas perduoti, todėl koncentratorius su tobula push eilute vis tiek numeta srautą vienu šuoliu vėliau. Tai įprasta priežastis, kodėl žmonės daro išvadą, kad push nepavyko.

Suteikite koncentratoriui tikrą išėjimo maršrutą

Koncentratoriui reikia savo kito šuolio būstinės prefiksui. Maršrutizuotame tunelyje tai paprastas maršrutas per sąsają tarp vietų, ir viena komanda parodo ir pasirinktą maršrutą, ir pasirinktą šaltinį:

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

Kai tarpvietės atkarpa pati yra OpenVPN, maršrutas gali gyventi toje konfigūracijoje, o partnerio tunelio adresas naudojamas kaip šliuzas: route 10.20.0.0 255.255.255.0 172.30.0.2. Šliuzas nėra pasirenkamas. Jei jo neįtrauksite, kitas šuolis nukris į įgyvendinimo numatytąją reikšmę, kuri skiriasi tarp vieno partnerio kliento ir kelių partnerių koncentratoriaus.

Taisyklėmis pagrįstas IPsec yra kitoks: koncentratoriaus branduolys siunčia paketą į savo įprastą LAN šliuzą, o taisyklė jį pagauna išėjime, todėl tunelio maršrutas arba nieko nedaro, arba nukreipia srautą pro taisyklę. Stebėkite šaltinį aukščiau esančioje komandoje, nes 10.10.0.1 vietoj telkinio adreso reiškia, kad branduolys pasirinko adresą, kurį tolimoji pusė atmes. iroute taip pat nėra atsakymas; jis pasako serveriui, kuris klientas turi potinklį už savo tunelio, o ne kur siųsti srautą trečiajai vietai.

Išplėskite tolimąją pusę iki naudotojų telkinio

Būstinė jau apima koncentratoriaus LAN, 10.10.0.0/24. Naudotojų telkinys yra antrasis prefiksas ir taip pat turi būti selektoriuose, kitaip jokia taisyklė neapima atsakymo, adresuoto 10.80.0.25. Kiekvienas partneris įvardija tą pačią prefiksų rinkinių porą iš savo pusės:

# 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

Vieno įrenginio local_ts yra kito remote_ts. Nukopijuokite koncentratoriaus bloką į būstinę ir pora apsiverčia, todėl child SA niekada nekeliama.

Senoji ipsec.conf sintaksė naudoja kableliais atskirtą leftsubnet. Veikianti saugos asociacija išlaiko suderėtus selektorius, todėl po pakeitimo iš naujo sukurkite tunelį. Selektoriaus, pakeisto 10:00 ir patikrinto su SA, pakelta 09:40, vis tiek nepavyksta, nors konfigūracijos failas visą laiką atrodo teisingas.

Tada patikrinkite paskutinį šuolį. ip route get 10.80.0.25 tolimajame galiniame taške turėtų rodyti į tunelį. Jei paslauga naudoja LAN maršrutizatorių kaip numatytąjį šliuzą, tam maršrutizatoriui taip pat reikia grįžimo maršruto, kitaip atsakymas ten žūva. tcpdump -ni eth1 host 10.80.0.25 tame segmente parodo, ar atsakymas apskritai paliko galinį tašką.

Leiskite srautą koncentratoriuje

Perdavimas turi būti įjungtas ir kelias leistas. Apribokite taisykles dviem prefiksams, o ne priimkite viską tarp sąsajų.

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

Atvirkštinio kelio filtravimas yra tylioji klaida šalia: kai dvi atkarpos yra skirtingose sąsajose, rp_filter=1 gali numesti atsakymą, o priėmimo taisyklės skaitiklis niekada nejuda. Palyginkite iptables -vnL FORWARD prieš bandymą ir po jo. Taisyklė, kuri niekada nedidėja, nepasiekiama, todėl žiūrėkite sluoksniu žemiau, o ne perrašykite ją.

Jei tranzito reikia tik vienai grupei, įdėkite maršrutą į failą pagal klientą kataloge client-config-dir vietoj to, kad išplėstumėte visuotinį push. Šaltinio NAT koncentratoriuje taip pat pašalina tolimosios pusės grįžimo maršruto poreikį, bet paslepia naudotojo adresą, todėl tolimosios vietos žurnalai ir adresais pagrįstos taisyklės nustoja skirti naudotojus.

Patikrinkite iš kliento, tada atšaukite atvirkštine tvarka

Testuokite TCP prievadą, o ne tik ICMP, nes ping gali praeiti, kol paslauga lieka užblokuota. nc -vz 10.20.0.50 445 ir traceroute -n 10.20.0.50 iš kliento parodo, ar antrasis šuolis yra koncentratoriaus tunelio adresas. Koncentratoriuje tcpdump -ni tun0 host 10.20.0.50 ir tas pats filtras sąsajoje tarp vietų: užklausa abiejuose be atsakymo nė viename perkelia problemą į tolimąją pusę.

Tada išbandykite tai, kas turi likti užblokuota. Jei atsako ir kompiuteris, kurio telkinys niekada neturėtų pasiekti, atidarėte daugiau nei tranzitą ir turėtumėte susiaurinti taisykles. Koncentratorius, kuris viską perduoda kiekvienai šakai, praeina pirmąjį testą ir nepraeina antrojo.

Laikykite atšaukimo sąrašą, nes pasikeitė keturi objektai, o tris lengva pamiršti: stumiamas maršrutas, koncentratoriaus maršrutas, selektoriai ir ugniasienės taisyklės. Atšaukite juos atvirkštine tvarka, iš naujo nustatykite SA ir leiskite vienam naudotojui prisijungti iš naujo. Dalinis atšaukimas palieka maršrutą, nukreiptą į tunelį, kuris nebeatitinka, o tai sunkiau skaityti nei pradinė tyla. OpenVPN 2.6 vadovas dokumentuoja push, route ir iroute jūsų versijai.