VPN site-to-site o remote access: ano ang pinag-uugnay ng bawat isa

Parehong tinatawag na VPN ang dalawang disenyo at iba ang nilulutas nilang problema. Ang site-to-site tunnel ay nag-uugnay ng dalawang gateway, kaya ang bawat host sa likod nila ay makakaabot sa pinapayagang address sa kabilang panig nang walang iniinstall. Ang remote-access tunnel ay nag-uugnay ng indibidwal na device sa isang network, isang client sa isang pagkakataon. Mahalaga ang paghahambing dahil karamihan ng error sa deployment ay nagmumula sa pag-configure ng isa habang inaasahan ang pag-uugali ng isa pa, at ang sintomas ay kadalasang timeout sa isang serbisyo na talagang naabot ng tunnel.

Dalawang disenyo, dalawang hangganan

Wala sa dalawang disenyo ang nagpapalawak ng LAN broadcast domain. Ang mga device sa kabilang panig ay hindi lumalabas sa lokal na listahan ng discovery, at ang umasa doon ang unang palagay na dapat bitawan. Ang mga pribadong DNS name na sinasadya mong ilathala ay mas mahuhulaan kaysa alinmang discovery protocol, at nananatili sila kahit magpalit ng vendor.

Kumuha ng 10.10.0.0/24 sa isang site at 10.20.0.0/24 sa isa pa. Kailangan ng gateway A ng ruta o traffic selector na nagpapadala ng prefix na 10.20.0.0/24 papasok sa tunnel, at kailangan ng gateway B ng salamin nito. Pagkatapos ay gumagamit ang mga host sa magkabilang panig ng ordinaryong IP connectivity at hindi nila alam na may tunnel. Ang pagiging di-nakikita ay ang feature, at iyon din ang dahilan kung bakit ang mga pagpalya ay mukhang ordinaryong error sa network at hindi error sa tunnel.

Ang policy-based at route-based ay hindi ang parehong tunnel

Sa policy-based na IPsec deployment, tinutukoy ng napagkasunduang traffic selector ang eksaktong pares ng source at destination na protektado. Kung may lumabas na bagong subnet sa likod ng isang gateway at walang selector na sumasaklaw dito, mananatiling buhay ang tunnel at ang bagong subnet ay hindi lang dinadala. Sa route-based na disenyo, ang interface ang tumatanggap ng traffic at ang routing table ang nagpapasya, kaya ang pagdaragdag ng prefix ay pagbabago sa ruta at hindi muling negosasyon ng tunnel.

Direktang ipinapakita ng StrongSwan ang dalawang pananaw, at ang pagsasama-sama ng pagbasa sa mga ito ang paraan para malaman kung aling modelo ang talagang inilagay mo.

swanctl --list-sas
ip xfrm policy
ip -4 route show table all | grep -E '10\.(10|20)\.'

Ang listahan ng selector na kulang sa prefix na kailangan mo ay nagpapaliwanag ng pagpalya nang walang anumang packet capture, at ang rutang tumuturo sa maling interface ay nagpapaliwanag ng salamin na pagpalya sa pagbabalik. Basahin ang dalawa bago muling makipagnegosasyon, dahil ang pag-renew ng key ay hindi magdaragdag ng selector na hindi mo kailanman na-configure.

Planuhin ang addressing bago ang tunnel

Ang magkakapatong na range ang error sa disenyo na hindi kayang ayusin ng configuration. Kung parehong gumagamit ng 192.168.1.0/24 ang dalawang site, ang host na nangangailangan ng 192.168.1.50 ay may dalawang kandidato at walang paraan upang pumili. Magpapatunay ang tunnel, maitatatag ang security associations, at mali o malabo pa rin ang desisyon sa routing.

Pumili ng isa sa tatlong tapat na opsyon: muling bilangin ang isang site, isalin ang magkakapatong na range sa gateway upang makita ng bawat panig ang naiibang prefix, o bitawan ang direktang routing para sa mga host na iyon at ilathala ang serbisyo sa ibang paraan. May gastos ang bawat isa, at ang una ang kadalasang pinakamura sa dalawang taong abot-tanaw. Magpasya bago pa umiral ang tunnel, dahil pagkatapos ay maaapektuhan ng pagbabago ang bawat device na may lumang address.

Ayusin din ang usapin ng MTU nang maaga. Binabawasan ng tunnel ang nagagamit na payload, at ang disenyong umaasa sa fragmentation ay kakaiba ang pag-uugali kaysa sa isang nagpi-fix ng MSS sa mga gateway.

Ang forwarding at patakaran ay nasa labas ng tunnel

Dapat pumayag ang gateway na mag-forward ng packet sa pagitan ng tunnel interface at LAN interface, at kailangan ng parehong direksyon ng patakarang nagpapahintulot sa serbisyo. Sa Linux ito ay dalawang magkahiwalay na setting, kasama ang mga firewall rule na nagpapasya kung pinapayagan ang na-forward na daloy.

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -s 10.20.0.0/24 -d 10.10.0.0/24 -j ACCEPT
iptables -A FORWARD -s 10.10.0.0/24 -d 10.20.0.0/24 -j ACCEPT

Nagdadagdag ang tumatanggap na host ng ikatlong antas: kailangan pa ring tanggapin ng sarili nitong firewall ang client mula sa malayong subnet. Ang file server na pinapayagan lang ang sarili nitong lokal na /24 ay tatanggihan ang na-forward na traffic mula sa 10.20.0.7, gaano man kaganda ang tunnel, at ang pagtanggi na iyon ay madaling basahin bilang pagpalya sa routing.

Subukan mula sa host, hindi mula sa gateway

Ang ping na ipinapadala ng gateway mismo ay maaaring sumunod sa naiibang source address at naiibang patakaran kaysa sa na-forward na traffic ng user. Ginagawa nitong mahinang pagsubok ito at kung minsan ay nakaliligaw: nagtatagumpay ito habang nabibigo ang application, o nabibigo habang gumagana ang application.

ip route get 10.10.0.5 from 10.20.0.7
ping -I 10.20.0.7 10.10.0.5
curl -sv --max-time 5 http://files.10-10.internal/ -o /dev/null

Gumamit ng tunay na host, tunay na source address at tunay na protocol na ginagamit ng application. Pagkatapos ay basahin nang hiwalay ang daan pabalik, dahil ang gumaganang pasulong na direksyon na walang return route ay gumagawa ng timeout na kahawig ng naka-block na serbisyo.

Piliin ang disenyo ayon sa tanong na sinasagot mo: nag-uugnay ka ba ng network o tumatanggap ka ng device? Lahat ng iba pa, kabilang ang aling vendor ang iko-configure mo, ay nagmumula sa sagot na iyon.