Aldoni duan subreton al VPN inter retejoj: du vojoj

Aldoni duan subreton al funkcianta tunelo inter retejoj daŭras kvin minutojn en unu dezajno kaj preskaŭ la tutan posttagmezon en la alia. Kiam la tunelo instalas vojojn por la prefiksoj, kiujn vi nomas, vi aldonas vojon kaj la trafiko sekvas ĝin. Kiam ĝi interkonsentas unu fiksan paron da selektiloj, la nova prefikso restas neprotektita ĝis ambaŭ flankoj konsentos pri kongrua paro. Tri aferoj decidas vian kazon: kion la agordo de ĉiu flanko vere priskribas, ĉu la interkonsentita trafiko mallarĝiĝas al la plej malgranda kongrua paro, kaj kiu posedas la revenan vojon por la nova gamo.

Legu la kernon, ne la statusan etikedon

Tunelo, kiu raportas konekton, instalas almenaŭ unu infanan asociadon, sed ne nepre tiun, kiun vi pensas. En Linux la kerno montras, kio aplikiĝas: ip xfrm policy listigas la parojn da selektiloj, kaj swanctl --list-sas (aŭ la pli malnova ipsec statusall) montras, kion la flankoj interkonsentis, inkluzive de la trafikaj selektiloj en ĉiu direkto. Se la nova prefikso aperas en neniu, ĝi estas neprotektita, kion ajn diras la agorda dosiero.

Komparu tion kun la vojtablo. En voj-bazita aranĝo la tunela aparato estas la sekva salteto por la protektitaj prefiksoj. Politik-bazita aranĝo ofte ne havas specifan vojon por la fora subreto, nur la defaŭltan vojon, ĉar la politiko elektas la trafikon, ne la tabelo.

Politik-bazitaj tuneloj: ambaŭ flankoj devas listigi la novan prefikson

En la terminaro de strongSwan la selektilo loĝas en local_ts kaj remote_ts sub la infana agordo, la posteuloj de leftsubnet kaj rightsubnet. La nova prefikso devas aperi ambaŭflanke spegule: kion retejo A nomas loka, retejo B nomas fora. Miskongruo malofte donas puran eraron. La flankoj mallarĝiĝas al la komunaĵo, la malnova prefikso daŭre funkcias kaj nur la nova malsukcesas silente.

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

Ĉe pfSense aŭ OPNsense tio signifas duan Phase 2-ensĉribon, kiu parigas la novan lokan subreton kun la nova fora, kaj poste apliki. Konservu la malnovan enskribon; anstataŭigo movas la originalan subreton anstataŭ aldoni ĝin. Se ekzistanta Phase 2 jam kovras superreton kiel 0.0.0.0/0 aŭ resumitan gamon, ne aldonu pli mallarĝan enskribon apude: interkovrantaj selektiloj instalas konkurantajn politikojn, kaj la taksada ordo decidas la venkinton.

IKEv1 faras ĉiun paron da subretoj propra Phase 2, kaj flanko, kiu prenas unu paron por interŝanĝo, forĵetas la ceterajn. IKEv2 povas porti plurajn parojn da selektiloj en unu infana asociado, sed nur se ambaŭ realigoj akceptas ilin. La listo el swanctl --list-sas estas la vero; tio, kion vi tajpis, estas peto.

Voj-bazitaj tuneloj: la vojo estas la politiko

XFRM-interfaco aŭ VTI-aparato portas trafikon laŭ la vojtablo. Vi direktas la novan prefikson al la aparato en ambaŭ retejoj, kaj la stato ligita al la transformo de la interfaco aplikiĝas. Ne estas paro da selektiloj por sinkronigi, tial ĉi tiu dezajno skaliĝas pli bone kiam subretoj multiĝas. La gvidilo de strongSwan pri plusendado traktas la kernan flankon detale.

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

WireGuard iras plu. AllowedIPs estas samtempe la kripta permeslisto kaj, per wg-quick, la enskribo en la vojtablo. Aldonu la prefikson nur unuflanke kaj vi ricevos manpremon, elirajn pakojn kaj silenton, ĉar la fora flanko forĵetas pakojn kies fonto ne estas en ĝia listo. La formo wg set anstataŭigas la tutan liston, do ripetu la prefiksojn, kiuj jam funkciis, alie vi fortranĉos ilin:

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

Tiu dua komando ne estas laŭvola kiam vi uzis wg set anstataŭ wg-quick. La kerno akceptas la novan permesliston tuj, sed nenio aldonas vojon por ĝi, do loke generita trafiko ankoraŭ eliras tra la defaŭlta enirejo. Tio estas la plej ofta kialo, kial nova WireGuard-subreto funkcias de la tunela gastigo kaj ne de tekkomputilo.

La reva vojo malsukcesas pli ofte ol la tunelo

Gastigoj en la nova fora subreto devas resendi respondojn tra la VPN-enirejo. Kiam tiu enirejo ne estas ilia defaŭlta enkursigilo, la respondo iras al la LAN-enkursigilo, kiu aŭ forĵetas ĝin aŭ plusendas ĝin al la interreto kun privata fonta adreso. Testu de gastigo ĉe la fora flanko anstataŭ de la enirejo: ip route get 10.30.20.15 en Linux aŭ Find-NetRoute -RemoteIPAddress 10.30.20.15 en PowerShell montras la sekvan salteton, kiun la gastigo vere uzos. Se la respondo ne estas la finpunkto de la tunelo, aldonu tie senmovan vojon por la nova prefikso.

Fonta NAT ĉe la retejo, kiu malhavas la revan vojon, estas laŭleĝa alternativo kaj la maniero, kiel multaj hub-and-spoke aranĝoj evitas tuŝi ĉiun servanton. Apliku ĝin ankaŭ al la nova prefikso ĉe la enirejo de la cela flanko:

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

La kosto estas reala. Foraj protokoloj ĉesas montri individuajn fontajn adresojn, kaj fajroŝirmilaj reguloj ligitaj al la originala subreto kunfandiĝas en unu regulon por la enirejo. Elektu tion konscie, ne ĉar mankis vojo.

Fajroŝirmiloj estas la alia duono de la reva vojo. Zon-bazitaj aparatoj ne aŭtomate etendas la zonon de ekzistanta tunela interfaco al nova subreto, kaj regulo skribita por la malnova prefikso ne kongruos. Aldonu la novan subreton al la zono aŭ al la regula paro en ambaŭ direktoj antaŭ ol kulpigi IPsec.

Decidu per tri demandoj, poste kontrolu per trafiko

La mallonga versio: ĉu la agordo de la flanko nomas prefiksojn (politik-bazita), aŭ ĉu trafiko enkursiĝas en interfacon (voj-bazita)? Ĉu ambaŭ finoj listigas la novan prefikson? Ĉu ekzistas vojo reen de la nova subreto al la originala fonta gamo?

Kontrolado estas kie plej multaj ŝanĝoj fermiĝas tro frue. Pinglo de la enirejo pruvas malmulte, ĉar la enirejo fontas el si mem kaj ofte kongruas kun alia politiko ol gastigo. Pinglu de gastigo en la nova subreto, poste rulu la aplikaĵon, kiu kaŭzis la ŝanĝon, kaj rigardu nombrilojn anstataŭ statusan ikonon.

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

Ĉe politik-bazita tunelo la nombriloj de ip xfrm state devus altiĝi en ambaŭ direktoj; ebenaj nombriloj signifas, ke la pako enkursiĝas sed ne elektiĝas. Ĉe WireGuard wg show raportas transigon por flanko, kaj manpremo kun nulo da ricevitaj bajtoj montras al la permeslisto de la fora flanko aŭ al ĝia reva vojo.

Finu registrante la prefikson, la selektilon aŭ vojon de la flanko, la decidon pri la reva vojo kaj la fajroŝirmilan enskribon kune kun la resto de la tunela inventaro. Poste restartigu unu enirejon kaj testu denove: vojo aldonita mane malaperas, kaj la sekva persono ne devus relegi tion.