Hindi maabot ng mga malayong user ang pangalawang site sa pamamagitan ng VPN hub

Kumokonekta ang isang malayong user sa hub, naaabot ang file server sa sariling LAN ng hub, at mukhang maayos ang lahat. Pagkatapos ay binubuksan niya ang isang share sa 10.20.0.50 sa punong tanggapan, na naaabot ng hub sa pamamagitan ng hiwalay na site-to-site tunnel, at nag-time out ito. Nakataas ang dalawang tunnel at tumataas ang dalawang counter, kaya walang sirang tunnel. Ang pagtawid sa hub ay tatlong desisyon sa routing sa tatlong device, at ang tunnel ay nagdadala lamang ng mga prefix na ginawa para dito. Narito ang pagkakasunod-sunod na sinusuri ko, at ang command na nagpapakita kung totoo ang bawat hakbang.

Kailangan ng tatlong paghahanap ang transit, hindi isang tunnel

Bawat device ay gumagawa ng sariling tugma sa pinakamahabang prefix at nakakalimutan ito. Dapat ipadala ng laptop ang 10.20.0.50 sa tunnel at hindi sa lokal nitong router. Dapat kunin ng hub ang packet na dumating sa remote-access interface at ibigay ito sa site-to-site interface. Dapat ipadala ng punong tanggapan ang sagot para sa address ng user pabalik sa tunnel. Alinman sa tatlong pagkabigo ay pareho ang hitsura sa browser: katahimikan.

Iyon ang dahilan kung bakit napakakaunting pinapatunayan ng pagsubok sa bawat tunnel nang mag-isa. Ang pag-ping sa LAN address ng hub ay nagsasanay sa unang desisyon, at ang pag-ping sa hub mula sa punong tanggapan ay nagsasanay sa pangatlo. Ang packet na nabigo ay may pool ng user bilang pinagmulan at ang pangalawang site bilang destinasyon, kaya isulat muna ang mga prefix na iyon. Dito ang pool ay 10.80.0.0/24, ang LAN ng hub ay 10.10.0.0/24 at ang punong tanggapan ay 10.20.0.0/24.

Itulak ang malayong prefix sa malayong kliyente

Sa isang OpenVPN remote-access server, natututuhan ng kliyente ang mga ruta sa oras ng pagkonekta. Kung walang push, ang kliyenteng may split tunnel ay nagpapadala ng 10.20.0.50 sa sarili nitong gateway at hindi kailanman pumapasok ang packet sa tunnel.

push "route 10.20.0.0 255.255.255.0"

Nagiging aktibo ang itinulak na ruta kapag kumonekta ang kliyente, kaya ang user na nananatiling online ay walang nakikita hanggang sa muling kumonekta. I-verify sa kliyente: ip route get 10.20.0.50 sa Linux, route print sa Windows. Dapat pangalanan ng output ang tunnel interface.

Hindi tumutulong ang push sa hub. Ito ay mensahe sa kliyente, hindi ruta sa server at hindi pahintulot na magpasa, kaya ang hub na may perpektong push line ay nagbabagsak pa rin ng flow isang hop mamaya. Ito ang karaniwang dahilan kung bakit napagpasyahan ng mga tao na nabigo ang push.

Bigyan ang hub ng tunay na ruta ng labasan

Kailangan ng hub ng sarili nitong susunod na hop para sa prefix ng punong tanggapan. Sa isang routed tunnel, ito ay ordinaryong ruta sa site-to-site interface, at ang isang command ay nagpapakita ng parehong piniling ruta at piniling pinagmulan:

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

Kung ang site-to-site leg mismo ay OpenVPN, ang ruta ay maaaring manirahan sa configuration na iyon na may tunnel address ng peer bilang gateway: route 10.20.0.0 255.255.255.0 172.30.0.2. Hindi opsyonal ang gateway. Kung aalisin mo ito, babagsak ang susunod na hop sa default ng implementasyon, na naiiba sa pagitan ng kliyenteng may isang malayong punto at hub na may maraming peer.

Iba ang IPsec na nakabatay sa patakaran: ipinapadala ng kernel ng hub ang packet sa normal nitong LAN gateway at hinuhuli ito ng patakaran sa paglabas, kaya ang ruta ng tunnel ay walang ginagawa o inilalayo ang traffic sa patakaran. Pansinin ang pinagmulan sa command sa itaas, dahil ang 10.10.0.1 sa halip na address ng pool ay nangangahulugang pumili ang kernel ng address na tatanggihan ng dulong bahagi. Hindi rin sagot ang iroute; sinasabi nito sa server kung aling kliyente ang may-ari ng subnet sa likod ng sarili nitong tunnel, hindi kung saan ipapadala ang traffic para sa pangatlong site.

Palawakin ang dulong bahagi hanggang sa pool ng user

Sakop na ng punong tanggapan ang LAN ng hub, 10.10.0.0/24. Ang pool ng user ay pangalawang prefix at dapat ding nasa mga selector, kung hindi ay walang patakarang sumasakop sa sagot na nakadirekta sa 10.80.0.25. Pinapangalanan ng bawat peer ang parehong pares ng mga set ng prefix mula sa sariling panig:

# 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

Ang local_ts ng isang device ay ang remote_ts ng isa. Kopyahin ang block ng hub sa punong tanggapan at mababaligtad ang pares, kaya hindi kailanman nakakataas ang child SA.

Ginagamit ng mas lumang syntax na ipsec.conf ang leftsubnet na pinaghihiwalay ng kuwit. Pinapanatili ng tumatakbong security association ang mga selector na napagkasunduan nito, kaya muling itatag ang tunnel pagkatapos ng pag-edit. Ang selector na binago nang 10:00 at sinubukan laban sa SA na nakataas nang 09:40 ay nabibigo pa rin, habang ang config file ay mukhang tama sa buong panahon.

Pagkatapos ay suriin ang huling hop. Dapat tumuro ang ip route get 10.80.0.25 sa dulong endpoint patungo sa tunnel. Kung gumagamit ang serbisyo ng LAN router bilang default na gateway nito, kailangan din ng router na iyon ang ruta ng pagbabalik, kung hindi ay namamatay doon ang sagot. Ang pagpapatakbo ng tcpdump -ni eth1 host 10.80.0.25 sa segment na iyon ay nagpapakita kung umalis man lang ang sagot sa endpoint.

Payagan ang flow sa hub

Dapat naka-enable ang pagpapasa at pinapayagan ang landas. Limitahan ang mga tuntunin sa dalawang prefix sa halip na tanggapin ang lahat sa pagitan ng mga interface.

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

Ang reverse-path filtering ay ang tahimik na pagkabigo sa tabi nito: kapag ang dalawang leg ay nasa magkaibang interface, maaaring iwanan ng rp_filter=1 ang sagot habang ang counter ng accept rule ay hindi gumagalaw. Ihambing ang iptables -vnL FORWARD bago at pagkatapos ng isang pagtatangka. Ang tuntuning hindi kailanman tumataas ay hindi naaabot, kaya tumingin ng isang layer sa ibaba sa halip na muling isulat ito.

Kung isang grupo lang ang nangangailangan ng transit, ilagay ang ruta sa file ng bawat kliyente sa ilalim ng client-config-dir sa halip na palawakin ang global push. Tinatanggal din ng Source NAT sa hub ang pangangailangan ng ruta ng pagbabalik sa dulong bahagi, ngunit itinatago nito ang address ng user, kaya ang mga log ng malayong site at mga tuntuning nakabatay sa address ay hindi na nakikilala ang mga user.

I-verify mula sa kliyente, pagkatapos ay i-rollback sa kabaligtarang pagkakasunod-sunod

Subukan ang TCP port, hindi lang ICMP, dahil ang ping ay maaaring pumasa habang nananatiling naka-block ang serbisyo. nc -vz 10.20.0.50 445 at traceroute -n 10.20.0.50 mula sa kliyente ay nagpapakita kung ang pangalawang hop ay ang tunnel address ng hub. Sa hub, tcpdump -ni tun0 host 10.20.0.50 at ang parehong filter sa site-to-site interface: kahilingan sa dalawa nang walang sagot sa alinman ay naglilipat ng problema sa dulong bahagi.

Pagkatapos ay subukan ang isang bagay na dapat manatiling naka-block. Kung sumagot din ang host na hindi dapat maabot ng pool, nagbukas ka ng higit sa transit at dapat mong paliitin ang mga tuntunin. Ang hub na nagpapasa ng lahat sa bawat sanga ay pumasa sa unang pagsubok at nabibigo sa pangalawa.

Magtago ng listahan ng rollback, dahil apat na bagay ang nabago at tatlo ang madaling makalimutan: ang itinulak na ruta, ang ruta ng hub, ang mga selector at ang mga tuntunin ng firewall. Ibalik ang mga ito sa kabaligtarang pagkakasunod-sunod, muling itatag ang SA, at hayaan ang isang user na muling kumonekta. Ang bahagyang rollback ay nag-iiwan ng rutang tumuturo sa tunnel na hindi na tugma, at mas mahirap iyon basahin kaysa sa orihinal na katahimikan. Ang manwal ng OpenVPN 2.6 ay nagdodokumento ng push, route at iroute para sa iyong bersyon.