Kuongeza subnet ya pili kwenye VPN kati ya maeneo: njia mbili

Kuongeza subnet ya pili kwenye tunnel inayofanya kazi kati ya maeneo huchukua dakika tano katika muundo mmoja na karibu mchana mzima katika mwingine. Tunnel inapoweka njia za viambishi unavyotaja, unaongeza njia na trafiki inaifuata. Inapojadili jozi moja ya wateuzi isiyobadilika, kiambishi kipya kinabaki bila ulinzi hadi pande zote zikubaliane juu ya jozi inayolingana. Mambo matatu huamua: kile usanidi wa kila upande unaeleza kwa kweli, kama trafiki iliyojadiliwa inapunguzwa hadi jozi ndogo inayolingana, na nani anamiliki njia ya kurudi kwa masafa mapya.

Soma kernel, si lebo ya hali

Tunnel inayoripoti muunganisho imeweka angalau muungano mmoja wa mtoto, lakini si lazima ule unaofikiri. Katika Linux kernel inaonyesha kinachotumika: ip xfrm policy huorodhesha jozi za wateuzi na swanctl --list-sas (au ipsec statusall la zamani) huonyesha kile pande zilikubaliana, pamoja na wateuzi wa trafiki katika kila mwelekeo. Kiambishi kipya kisipo katika zote mbili, hakina ulinzi, chochote faili ya usanidi inachosema.

Linganisha na jedwali la njia. Katika mpango unaotegemea njia, kifaa cha tunnel ni hatua inayofuata kwa viambishi vilivyolindwa. Mpango unaotegemea sera mara nyingi hauna njia maalum kwa subnet ya mbali, una njia ya msingi tu, kwa sababu sera ndiyo huchagua trafiki na si jedwali.

Inayotegemea sera: pande zote mbili ziorodheshe kiambishi kipya

Kwa maneno ya strongSwan mteuzi hukaa katika local_ts na remote_ts chini ya usanidi wa mtoto, warithi wa leftsubnet na rightsubnet. Kiambishi kipya lazima kionekane pande zote kama kioo: kile eneo A huita la ndani, eneo B huita la mbali. Kutokulingana mara chache hutoa kosa safi. Pande hupunguzwa hadi makutano, kiambishi cha zamani kinaendelea kufanya kazi na kipya pekee hushindwa kimya.

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

Katika pfSense au OPNsense hiyo inamaanisha ingizo la pili la Phase 2 linalooanisha subnet mpya ya ndani na ile ya mbali, kisha matumizi. Weka ingizo la zamani; kulibadilisha kuhamisha subnet ya awali badala ya kuiongeza. Ikiwa Phase 2 iliyopo tayari inashughulikia supernet kama 0.0.0.0/0 au masafa yaliyofupishwa, usiongeze ingizo jembamba kando yake: wateuzi wanaopishana huweka sera shindani na mpangilio wa tathmini huamua mshindi.

IKEv1 hufanya kila jozi ya subnet kuwa Phase 2 yake, na upande unaokubali jozi moja kwa kubadilishana huacha zingine. IKEv2 inaweza kubeba jozi kadhaa za wateuzi katika mtoto mmoja, lakini tu ikiwa utekelezaji wote wawili unazikubali. Orodha kutoka swanctl --list-sas ndiyo ukweli; ulichoandika ni ombi.

Inayotegemea njia: njia ndiyo sera

Kiolesura cha XFRM au kifaa cha VTI hubeba trafiki kulingana na jedwali la njia. Unaelekeza kiambishi kipya kwenye kifaa katika maeneo yote mawili, na hali iliyofungwa na mabadiliko ya kiolesura hutumika. Hakuna jozi ya wateuzi ya kuoanisha, ndiyo sababu muundo huu hukua vizuri kadri subnet zinavyoongezeka. Mwongozo wa strongSwan wa upelekaji unaeleza upande wa kernel kwa kina.

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

WireGuard inaenda mbele zaidi. AllowedIPs ni orodha ya ruhusa za kripto na, kupitia wg-quick, ingizo la jedwali la njia. Ongeza kiambishi upande mmoja tu na utapata kupeana mikono, pakiti zinazotoka na ukimya, kwa sababu upande wa mbali hutupa pakiti ambazo chanzo chake hakiko kwenye orodha yake. Umbo wg set hubadilisha orodha yote, kwa hiyo rudia viambishi vilivyokuwa vikifanya kazi au utavikata:

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

Amri ya pili si ya hiari ulipotumia wg set badala ya wg-quick. Kernel hukubali orodha mpya mara moja, lakini hakuna kinachoongeza njia kwa ajili yake, kwa hiyo trafiki inayoundwa ndani bado inatoka kwa lango la msingi. Hii ni sababu ya kawaida zaidi kwa nini subnet mpya ya WireGuard inafanya kazi kutoka kwa mwenyeji wa tunnel na si kutoka kwa laptop.

Njia ya kurudi hushindwa mara nyingi zaidi kuliko tunnel

Wenyeji kwenye subnet mpya ya mbali lazima watume majibu kupitia lango la VPN. Lango hilo lisipokuwa kipanga njia chao cha msingi, jibu huenda kwa kipanga njia cha LAN, ambacho hulitupa au hulisambaza kwenye intaneti na anwani ya chanzo ya faragha. Jaribu kutoka kwa mwenyeji upande wa mbali, si kutoka kwa lango: ip route get 10.30.20.15 katika Linux au Find-NetRoute -RemoteIPAddress 10.30.20.15 katika PowerShell huonyesha hatua inayofuata ambayo mwenyeji atatumia kweli. Ikiwa jibu si mwisho wa tunnel, ongeza njia tuli kwa kiambishi kipya hapo.

NAT ya chanzo katika eneo lisilo na njia ya kurudi ni mbadala halali na njia ambayo mipangilio mingi ya hub-and-spoke huepuka kugusa kila seva. Itumie pia kwa kiambishi kipya kwenye lango la upande wa mwisho:

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

Gharama ni ya kweli. Kumbukumbu za mbali huacha kuonyesha anwani za chanzo binafsi, na kanuni za firewall zinazotegemea subnet ya awali huungana kuwa kanuni moja kwa lango. Chagua hilo kwa makusudi, si kwa sababu njia ilikosekana.

Firewall ni nusu nyingine ya njia ya kurudi. Vifaa vinavyotegemea kanda hazipanui kanda ya kiolesura cha tunnel kilichopo hadi subnet mpya kiotomatiki, na kanuni iliyoandikwa kwa kiambishi cha zamani haitalingana. Ongeza subnet mpya kwenye kanda au kwenye jozi ya kanuni pande zote mbili kabla ya kulaumu IPsec.

Amua kwa maswali matatu, kisha thibitisha kwa trafiki

Toleo fupi: usanidi wa upande hutaja viambishi (inayotegemea sera), au trafiki inaelekezwa kwenye kiolesura (inayotegemea njia)? Pande zote mbili zinaorodhesha kiambishi kipya? Kuna njia ya kurudi kutoka subnet mpya hadi masafa ya awali ya chanzo?

Uthibitishaji ndipo mabadiliko mengi hufungwa mapema mno. Ping kutoka kwa lango huthibitisha kidogo, kwa sababu lango hutuma kutoka kwake na mara nyingi hulingana na sera tofauti na mwenyeji. Ping kutoka kwa mwenyeji kwenye subnet mpya, kisha endesha programu iliyosababisha mabadiliko na uangalie vihesabu, si ikoni ya hali.

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

Kwenye tunnel inayotegemea sera vihesabu vya ip xfrm state vinapaswa kupanda pande zote mbili; vihesabu tambarare vinamaanisha pakiti imeelekezwa lakini haikuchaguliwa. Kwenye WireGuard wg show huripoti uhamishaji kwa upande, na kupeana mikono kwa baiti sifuri zilizopokelewa huashiria orodha ya upande wa mbali au njia yake ya kurudi.

Maliza kwa kurekodi kiambishi, mteuzi au njia ya upande, uamuzi wa njia ya kurudi na ingizo la firewall pamoja na orodha iliyobaki ya tunnel. Kisha anza upya lango moja na ujaribu tena: njia iliyoongezwa kwa mkono hupotea, na mtu anayefuata hapaswi kuigundua tena.