Pagdaragdag ng ikalawang subnet sa isang site-to-site VPN: dalawang daan

Ang pagdaragdag ng ikalawang subnet sa isang site-to-site tunnel na gumagana ay tumatagal ng limang minuto sa isang disenyo at halos buong hapon sa isa pa. Kapag naglalagay ang tunnel ng mga ruta para sa mga prefix na pinangalanan mo, nagdadagdag ka ng ruta at sinusundan ito ng trapiko. Kapag nakikipagkasundo ito sa isang takdang pares ng tagapili, nananatiling walang proteksyon ang bagong prefix hanggang magkasundo ang dalawang panig sa tugmang pares. Tatlong bagay ang nagpapasya: ano ang tunay na inilalarawan ng config ng bawat panig, kung ang napagkasunduang trapiko ay pumipino sa pinakamaliit na tugmang pares, at kanino ang pabalik na ruta ng bagong saklaw.

Basahin ang kernel, hindi ang label ng estado

Ang tunnel na nag-uulat ng koneksyon ay naglagay ng hindi bababa sa isang child association, ngunit hindi laging ang inaasahan mo. Sa Linux ipinapakita ng kernel kung ano ang inilalapat: inililista ng ip xfrm policy ang mga pares ng tagapili at ipinapakita ng swanctl --list-sas (o ng lumang ipsec statusall) ang napagkasunduan ng magkabilang panig, kasama ang mga tagapili ng trapiko sa bawat direksyon. Kung wala ang bagong prefix sa alinman, wala itong proteksyon, ano man ang sabihin ng config file.

Ihambing ito sa talahanayan ng ruta. Sa rutang-batay na disenyo ang device ng tunnel ang susunod na hop para sa mga protektadong prefix. Ang patakarang-batay na disenyo ay madalas walang partikular na ruta para sa malayong subnet, tanging ang default na ruta, dahil ang patakaran ang pumipili ng trapiko at hindi ang talahanayan.

Batay sa patakaran: dapat ilista ng dalawang panig ang bagong prefix

Sa terminolohiya ng strongSwan ang tagapili ay nasa local_ts at remote_ts sa ilalim ng child config, ang mga kahalili ng leftsubnet at rightsubnet. Dapat lumitaw ang bagong prefix sa dalawang panig nang parang salamin: ang tinatawag na lokal ng site A ay tinatawag na malayo ng site B. Bihirang magbigay ng malinaw na error ang pagkakaiba. Pumipino ang dalawang panig sa intersection, patuloy na gumagana ang lumang prefix at tanging ang bago ang tahimik na nabibigo.

swanctl --load-conns
swanctl --initiate --child <child-name>
swanctl --list-sas
ip xfrm policy

Sa pfSense o OPNsense ang ibig sabihin nito ay ikalawang entry ng Phase 2 na nagpapares ng bagong lokal na subnet sa bagong malayong subnet, at pagkatapos ay ilapat. Panatilihin ang lumang entry; ang pagpapalit nito ay inililipat ang orihinal na subnet sa halip na idagdag. Kung ang umiiral na Phase 2 ay sumasakop na sa isang supernet gaya ng 0.0.0.0/0 o pinagsamang saklaw, huwag magdagdag ng mas makitid na entry sa tabi nito: ang magkakapatong na tagapili ay naglalagay ng magkakumpitensyang patakaran at ang pagkakasunod-sunod ng pagsusuri ang nagpapasya ng mananalo.

Ginagawa ng IKEv1 na sariling Phase 2 ang bawat pares ng subnet, at ang panig na tumatanggap ng isang pares kada palitan ay itinatapon ang iba. Maaaring magdala ang IKEv2 ng ilang pares ng tagapili sa isang child, ngunit kung tatanggapin lamang ng dalawang implementasyon. Ang listahan mula sa swanctl --list-sas ang katotohanan; ang tinipa mo ay isang kahilingan.

Batay sa ruta: ang ruta ang patakaran

Ang interface ng XFRM o device na VTI ay nagdadala ng trapiko ayon sa talahanayan ng ruta. Itinuturo mo ang bagong prefix sa device sa dalawang site, at nalalapat ang estadong nakatali sa transpormasyon ng interface. Walang pares ng tagapili na isasaayos, kaya mas mahusay na lumalaki ang disenyong ito habang dumarami ang subnet. Detalyadong tinatalakay ng gabay ng strongSwan sa pagpapasa ang panig ng kernel.

ip route add 192.168.60.0/24 dev xfrm0
ip route get 192.168.60.10

Mas malayo ang WireGuard. Ang AllowedIPs ay parehong listahan ng pahintulot sa kripto at, sa pamamagitan ng wg-quick, ang entry sa talahanayan ng ruta. Magdagdag ng prefix sa isang panig lamang at makakakuha ka ng handshake, palabas na packet at katahimikan, dahil itinatapon ng malayong panig ang mga packet na wala ang pinagmulan sa listahan nito. Pinapalitan ng anyong wg set ang buong listahan, kaya ulitin ang mga prefix na gumana na, kung hindi ay puputulin mo ang mga ito:

wg set wg0 peer <PUBKEY> allowed-ips 192.168.10.0/24,192.168.60.0/24
ip route add 192.168.60.0/24 dev wg0

Ang ikalawang utos ay hindi opsyonal kapag ginamit mo ang wg set sa halip na wg-quick. Agad tinatanggap ng kernel ang bagong listahan, ngunit walang nagdaragdag ng ruta para dito, kaya ang trapikong nalikha sa lokal ay lumalabas pa rin sa default na gateway. Ito ang pinakakaraniwang dahilan kung bakit gumagana ang bagong subnet ng WireGuard mula sa host ng tunnel at hindi mula sa laptop.

Mas madalas mabigo ang pabalik na ruta kaysa sa tunnel

Dapat ipadala ng mga host sa bagong malayong subnet ang mga sagot pabalik sa gateway ng VPN. Kapag ang gateway na iyon ay hindi ang kanilang default na router ay pumupunta ang sagot sa router ng LAN, na itinatapon ito o ipinapasa sa internet na may pribadong address ng pinagmulan. Subukan mula sa host sa malayong panig, hindi mula sa gateway: ipinapakita ng ip route get 10.30.20.15 sa Linux o Find-NetRoute -RemoteIPAddress 10.30.20.15 sa PowerShell ang susunod na hop na talagang gagamitin ng host. Kung ang sagot ay hindi ang dulo ng tunnel, magdagdag doon ng static na ruta para sa bagong prefix.

Ang source NAT sa site na walang pabalik na ruta ay lehitimong alternatibo at paraan ng maraming hub-and-spoke deployment upang iwasang hawakan ang bawat server. Ilapat din ito sa bagong prefix sa gateway sa panig ng destinasyon:

iptables -t nat -A POSTROUTING -s 10.30.20.0/24 -d 192.168.60.0/24 -j MASQUERADE

Totoo ang halaga. Humihinto ang malalayong log sa pagpapakita ng indibidwal na address ng pinagmulan, at ang mga patakaran ng firewall na nakabatay sa orihinal na subnet ay nagiging isang patakaran para sa gateway. Piliin ito nang sadya, hindi dahil kulang ang ruta.

Ang firewall ang kabilang kalahati ng pabalik na ruta. Hindi awtomatikong pinalalawak ng mga device na batay sa zone ang zone ng umiiral na tunnel interface sa bagong subnet, at ang patakarang isinulat para sa lumang prefix ay hindi tutugma. Idagdag ang bagong subnet sa zone o sa pares ng patakaran sa dalawang direksyon bago sisihin ang IPsec.

Magpasya sa tatlong tanong, pagkatapos ay i-verify sa trapiko

Maikling bersyon: pinangalanan ba ng config ng panig ang mga prefix (batay sa patakaran), o ang trapiko ay irinuruta sa isang interface (batay sa ruta)? Inililista ba ng dalawang dulo ang bagong prefix? May daan ba pabalik mula sa bagong subnet patungo sa orihinal na saklaw ng pinagmulan?

Ang pag-verify ang lugar kung saan masyadong maaga isinasara ang karamihan ng pagbabago. Kaunti ang pinatutunayan ng ping mula sa gateway, dahil nagpapadala ito mula sa sarili at madalas tumutugma sa ibang patakaran kaysa sa host. Mag-ping mula sa host sa bagong subnet, pagkatapos patakbuhin ang application na nagtulak ng pagbabago, at tingnan ang mga counter hindi ang icon ng estado.

tcpdump -ni any host 192.168.60.10 and (esp or udp port 4500)
ip xfrm state
wg show

Sa tunnel na batay sa patakaran dapat tumaas ang mga counter ng ip xfrm state sa dalawang direksyon; ang pantay na counter ay nangangahulugang ang packet ay irinuruta ngunit hindi pinili. Sa WireGuard, iniuulat ng wg show ang paglilipat kada panig, at ang handshake na walang natanggap na byte ay tumuturo sa listahan ng malayong panig o sa pabalik na ruta nito.

Tapusin sa pagtatala ng prefix, tagapili o ruta ng panig, pasya sa pabalik na ruta at entry ng firewall kasama ang natitirang imbentaryo ng tunnel. Pagkatapos i-restart ang isang gateway at subukan muli: mawawala ang rutang idinagdag sa kamay, at hindi na kailangang tuklasin itong muli ng susunod na tao.