Attālinātie lietotāji netiek līdz otrajai vietai caur VPN centrmezglu

Attālināts lietotājs pieslēdzas centrmezglam, sasniedz failu serveri paša centrmezgla LAN tīklā, un viss izskatās vesels. Tad viņš atver koplietojumu adresē 10.20.0.50 galvenajā birojā, kuru centrmezgls sasniedz pa atsevišķu tuneli starp vietām, un tiek pārsniegts laika limits. Abi tuneļi ir aktīvi un abi skaitītāji aug, tāpēc neviens tunelis nav bojāts. Šķērsot centrmezglu ir trīs maršrutēšanas lēmumi trīs ierīcēs, un tunelis pārvadā tikai tos prefiksus, kuriem tas tika uzbūvēts. Lūk, kārtība, ko pārbaudu, un komanda, kas parāda, vai katrs solis ir patiess.

Caurgājiens prasa trīs meklējumus, nevis vienu tuneli

Katra ierīce veic savu garākā prefiksa atbilstību un aizmirst to. Klēpjdatoram jāsūta 10.20.0.50 tunelī, nevis savam vietējam maršrutētājam. Centrmezglam jāņem pakete, kas ieradās attālinātās piekļuves saskarnē, un jānodod to saskarnei starp vietām. Galvenajam birojam jāsūta atbilde uz lietotāja adresi atpakaļ pa tuneli. Ja neizdodas kaut viens no trim, pārlūkā tas izskatās vienādi: klusums.

Tāpēc katra tuneļa atsevišķa testēšana pierāda tik maz. Centrmezgla LAN adreses pingēšana trenē pirmo lēmumu, un centrmezgla pingēšana no galvenā biroja trenē trešo. Neizdevušās paketes avots ir lietotāju baseins un galamērķis ir otrā vieta, tāpēc vispirms pierakstiet šos prefiksus. Šeit baseins ir 10.80.0.0/24, centrmezgla LAN ir 10.10.0.0/24, un galvenais birojs ir 10.20.0.0/24.

Aizstūmiet tālo prefiksu tālajam klientam

Uz OpenVPN attālinātās piekļuves servera klients maršrutus apgūst pieslēgšanās brīdī. Bez push klients ar sadalītu tuneli sūta 10.20.0.50 uz savu vārteju, un pakete nekad neiekļūst tunelī.

push "route 10.20.0.0 255.255.255.0"

Aizstūmītais maršruts stājas spēkā, kad klients pieslēdzas, tāpēc lietotājs, kas paliek tiešsaistē, neko neredz, līdz pieslēdzas no jauna. Pārbaudiet klientā: ip route get 10.20.0.50 Linux sistēmā, route print Windows sistēmā. Izvadei jānosauc tuneļa saskarne.

Push centrmezglam nepalīdz. Tas ir ziņojums klientam, nevis maršruts serverī un nevis atļauja pārsūtīt, tāpēc centrmezgls ar perfektu push rindu joprojām nomet plūsmu vienu lēcienu vēlāk. Tas ir ierastais iemesls, kāpēc cilvēki secina, ka push ir neizdevies.

Dodiet centrmezglam reālu izejas maršrutu

Centrmezglam vajadzīgs savs nākamais lēciens galvenā biroja prefiksam. Maršrutētā tunelī tas ir parasts maršruts caur saskarni starp vietām, un viena komanda parāda gan izvēlēto maršrutu, gan izvēlēto avotu:

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

Ja starpvietu posms pats ir OpenVPN, maršruts var dzīvot tajā konfigurācijā, izmantojot partnera tuneļa adresi kā vārteju: route 10.20.0.0 255.255.255.0 172.30.0.2. Vārteja nav obligāta. Ja to izlaidīsiet, nākamais lēciens nokritīs uz ieviešanas noklusējumu, kas atšķiras starp viena partnera klientu un vairāku partneru centrmezglu.

Uz politiku balstīts IPsec ir citāds: centrmezgla kodols sūta paketi uz savu parasto LAN vārteju, un politika to pārtver izejā, tāpēc tuneļa maršruts vai nu neko nedara, vai arī virza satiksmi garām politikai. Vērojiet avotu iepriekš minētajā komandā, jo 10.10.0.1 baseina adreses vietā nozīmē, ka kodols izvēlējās adresi, kuru tālā puse noraidīs. iroute arī nav atbilde; tas pasaka serverim, kuram klientam pieder apakštīkls aiz sava tuneļa, nevis kur sūtīt satiksmi trešajai vietai.

Paplašiniet tālo pusi uz lietotāju baseinu

Galvenais birojs jau sedz centrmezgla LAN, 10.10.0.0/24. Lietotāju baseins ir otrs prefikss, un tam jābūt arī selektoros, citādi neviena politika nesedz atbildi, kas adresēta 10.80.0.25. Katrs partneris nosauc to pašu prefiksu kopu pāri no savas puses:

# 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

Vienas ierīces local_ts ir otras remote_ts. Nokopējiet centrmezgla bloku uz galveno biroju, un pāris apgriežas, tāpēc child SA nekad nepaceļas.

Vecākā ipsec.conf sintakse izmanto ar komatiem atdalītu leftsubnet. Darbojošā drošības asociācija patur sarunātos selektorus, tāpēc pēc rediģēšanas no jauna izveidojiet tuneli. Selektors, kas nomainīts 10:00 un pārbaudīts pret SA, kas pacēlās 09:40, joprojām neizdodas, lai gan konfigurācijas fails visu laiku izskatās pareizs.

Pēc tam pārbaudiet pēdējo lēcienu. ip route get 10.80.0.25 tālajā galapunktā vajadzētu norādīt tunelī. Ja pakalpojums izmanto LAN maršrutētāju kā noklusēto vārteju, arī tam maršrutētājam vajadzīgs atgriešanās maršruts, citādi atbilde tur iet bojā. tcpdump -ni eth1 host 10.80.0.25 šajā segmentā parāda, vai atbilde vispār pameta galapunktu.

Atļaujiet plūsmu centrmezglā

Pārsūtīšanai jābūt iespējotai un ceļam atļautam. Ierobežojiet noteikumus ar diviem prefiksiem, nevis pieņemiet visu starp saskarnēm.

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

Apgrieztā ceļa filtrēšana ir klusā kļūda tam blakus: ja abas kājas ir dažādās saskarnēs, rp_filter=1 var nomest atbildi, kamēr pieņemšanas noteikuma skaitītājs nekad nekustas. Salīdziniet iptables -vnL FORWARD pirms mēģinājuma un pēc tā. Noteikums, kas nekad nepieaug, netiek sasniegts, tāpēc skatieties slāni zemāk, nevis pārrakstiet to.

Ja caurgājiens vajadzīgs tikai vienai grupai, ievietojiet maršrutu failā katram klientam mapē client-config-dir nevis paplašiniet globālo push. Avota NAT centrmezglā arī novērš vajadzību pēc tālās puses atgriešanās maršruta, bet tas slēpj lietotāja adresi, tāpēc tālās vietas žurnāli un uz adresēm balstīti noteikumi vairs neatšķir lietotājus.

Pārbaudiet no klienta un pēc tam atritiniet apgrieztā secībā

Testējiet TCP portu, ne tikai ICMP, jo ping var iziet, kamēr pakalpojums paliek bloķēts. nc -vz 10.20.0.50 445 un traceroute -n 10.20.0.50 no klienta parāda, vai otrais lēciens ir centrmezgla tuneļa adrese. Centrmezglā tcpdump -ni tun0 host 10.20.0.50 un tas pats filtrs saskarnē starp vietām: pieprasījums abos bez atbildes nevienā pārvieto problēmu uz tālo pusi.

Pēc tam pārbaudiet kaut ko, kam jāpaliek bloķētam. Ja atbild arī resursdators, kuru baseinam nekad nevajadzētu sasniegt, jūs esat atvēruši vairāk par caurgājienu, un noteikumi jāsašaurina. Centrmezgls, kas visu pārsūta katrai atzarei, iztur pirmo testu un neiztur otro.

Uzturiet atritināšanas sarakstu, jo tika mainīti četri objekti un trīs ir viegli aizmirst: aizstūmītais maršruts, centrmezgla maršruts, selektori un ugunsmūra noteikumi. Atritiniet tos apgrieztā secībā, no jauna izveidojiet SA un ļaujiet vienam lietotājam pieslēgties no jauna. Daļēja atritināšana atstāj maršrutu, kas norāda uz tuneli, kurš vairs neatbilst, un to ir grūtāk lasīt nekā sākotnējo klusumu. OpenVPN 2.6 rokasgrāmata dokumentē push, route un iroute jūsu versijai.