Otrā apakštīkla pievienošana VPN starp vietnēm: divi ceļi
Uz politiku balstītiem tuneļiem vajag atbilstošus selektorus abās pusēs; uz maršrutiem balstītiem vajag maršrutu. Izvēlieties pareizo ceļu un vispirms salabojiet atgriešanās maršrutu.
Otra apakštīkla pievienošana strādājošam tunelim starp vietnēm vienā projektā aizņem piecas minūtes, otrā — gandrīz visu pēcpusdienu. Kad tunelis instalē maršrutus norādītajiem prefiksiem, pievienojat maršrutu un trafiks tam seko. Kad tas vienojas par vienu fiksētu selektoru pāri, jaunais prefikss paliek neaizsargāts, līdz abas puses vienojas par atbilstošu pāri. Izšķir trīs lietas: ko īsti apraksta katras puses konfigurācija, vai saskaņotais trafiks sašaurinās līdz mazākajam atbilstošajam pārim un kam pieder jaunā diapazona atgriešanās ceļš.
Lasiet kodolu, nevis statusa etiķeti
Tunelis, kas ziņo par savienojumu, ir instalējis vismaz vienu bērna asociāciju, bet ne vienmēr to, ko domājat. Linux kodols rāda, kas tiek piemērots: ip xfrm policy uzskaita selektoru pārus, un swanctl --list-sas (vai vecākais ipsec statusall) rāda, par ko puses vienojās, ieskaitot trafika selektorus katrā virzienā. Ja jaunā prefiksa nav nevienā, tas ir neaizsargāts, lai ko teiktu konfigurācijas fails.
Salīdziniet ar maršrutu tabulu. Uz maršrutiem balstītā sistēmā tuneļa ierīce ir nākamais lēciens aizsargātajiem prefiksiem. Uz politiku balstītā sistēmā bieži nav atsevišķa maršruta attālajam apakštīklam, tikai noklusējuma maršruts, jo trafiku izvēlas politika, nevis tabula.
Uz politiku balstīti tuneļi: abām pusēm jāuzskaita jaunais prefikss
strongSwan terminos selektors atrodas local_ts un remote_ts bērna konfigurācijā, leftsubnet un rightsubnet pēctečos. Jaunajam prefiksam jāparādās abās pusēs spoguļveidā: ko vieta A sauc par lokālu, vieta B sauc par attālu. Neatbilstība reti dod tīru kļūdu. Puses sašaurinās līdz krustojumam, vecais prefikss turpina strādāt, un tikai jaunais klusi neizdodas.
swanctl --load-conns
swanctl --initiate --child <child-name>
swanctl --list-sas
ip xfrm policypfSense vai OPNsense tas nozīmē otru Phase 2 ierakstu, kas savieno jauno lokālo apakštīklu ar jauno attālo, un pēc tam piemērošanu. Saglabājiet veco ierakstu; aizstāšana pārvieto sākotnējo apakštīklu, nevis pievieno. Ja esošais Phase 2 jau aptver virstīklu kā 0.0.0.0/0 vai apkopotu diapazonu, nepievienojiet blakus šaurāku ierakstu: pārklājošies selektori instalē konkurējošas politikas, un vērtēšanas kārtība nosaka uzvarētāju.
IKEv1 katru apakštīklu pāri padara par atsevišķu Phase 2, un puse, kas ņem vienu pāri uz apmaiņu, pārējos atmet. IKEv2 var nest vairākus selektoru pārus vienā bērnā, bet tikai ja abas implementācijas tos pieņem. Saraksts no swanctl --list-sas ir patiesība; tas, ko ierakstījāt, ir pieprasījums.
Uz maršrutiem balstīti tuneļi: maršruts ir politika
XFRM saskarne vai VTI ierīce nes trafiku saskaņā ar maršrutu tabulu. Jūs vēršat jauno prefiksu uz ierīci abās vietnēs, un tiek piemērots stāvoklis, kas saistīts ar saskarnes transformāciju. Nav selektoru pāra, ko sinhronizēt, tāpēc šis projekts labāk mērogojas, pieaugot apakštīkliem. strongSwan pāradresācijas rokasgrāmata detalizēti aplūko kodola pusi.
ip route add 192.168.60.0/24 dev xfrm0
ip route get 192.168.60.10WireGuard iet tālāk. AllowedIPs ir vienlaikus kriptogrāfiskais atļauto saraksts un, caur wg-quick, maršrutu tabulas ieraksts. Pievienojiet prefiksu tikai vienā pusē un iegūsiet rokasspiedienu, izejošos paketes un klusumu, jo tālā puse atmet paketes, kuru avots nav tās sarakstā. Forma wg set aizstāj visu sarakstu, tāpēc atkārtojiet jau strādājošos prefiksus, citādi jūs tos nogriezīsiet:
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 wg0Otrā komanda nav obligāta, ja izmantojāt wg set nevis wg-quick. Kodols jauno sarakstu pieņem uzreiz, bet nekas tam nepievieno maršrutu, tāpēc lokāli radītais trafiks joprojām iziet caur noklusējuma vārteju. Tas ir visbiežākais iemesls, kāpēc jauns WireGuard apakštīkls strādā no tuneļa resursdatora, nevis no portatīvā.
Atgriešanās ceļš sabojājas biežāk nekā tunelis
Jaunā attālā apakštīkla resursdatoriem atbildes jāsūta atpakaļ pa VPN vārteju. Kad šī vārteja nav to noklusējuma maršrutētājs, atbilde dodas uz LAN maršrutētāju, kas to atmet vai pārsūta uz internetu ar privātu avota adresi. Pārbaudiet no tālās puses resursdatora, nevis no vārtejas: ip route get 10.30.20.15 Linux vai Find-NetRoute -RemoteIPAddress 10.30.20.15 PowerShell rāda nākamo lēcienu, ko resursdators tiešām izmantos. Ja atbilde nav tuneļa galapunkts, pievienojiet tur statisku maršrutu jaunajam prefiksam.
Avota NAT vietnē, kurai trūkst atgriešanās maršruta, ir likumīga alternatīva un veids, kā daudzas hub-and-spoke ieviešanas izvairās aizskart katru serveri. Piemērojiet to arī jaunajam prefiksam galamērķa puses vārtejā:
iptables -t nat -A POSTROUTING -s 10.30.20.0/24 -d 192.168.60.0/24 -j MASQUERADEIzmaksa ir reāla. Attālie žurnāli pārstāj rādīt atsevišķas avota adreses, un ugunsmūra noteikumi, kas balstīti uz sākotnējo apakštīklu, saplūst vienā noteikumā vārtejai. Izvēlieties to apzināti, nevis tāpēc, ka trūka maršruta.
Ugunsmūri ir atgriešanās ceļa otra puse. Uz zonām balstītas ierīces automātiski nepaplašina esošas tuneļa saskarnes zonu uz jaunu apakštīklu, un noteikums, kas rakstīts vecajam prefiksam, nesakritīs. Pievienojiet jauno apakštīklu zonai vai noteikumu pārim abos virzienos, pirms vainojat IPsec.
Izlemiet ar trim jautājumiem, tad pārbaudiet ar trafiku
Īsā versija: vai puses konfigurācija nosauc prefiksus (uz politiku balstīta), vai trafiks tiek maršrutēts saskarnē (uz maršrutiem balstīta)? Vai abi gali uzskaita jauno prefiksu? Vai ir ceļš atpakaļ no jaunā apakštīkla uz sākotnējo avota diapazonu?
| Tunnel style | Where the prefix goes | What breaks if you skip it |
|---|---|---|
| Policy-based IPsec | Selector pair on both peers | Old subnets work, the new one fails with no clear error |
| Route-based XFRM or VTI | Route into the device on both sites | Packets routed but not transformed, or the state never matches |
| WireGuard | AllowedIPs on both peers plus a route | Handshake succeeds, replies are dropped |
| Overlapping supernet | Adjust the existing entry instead | A shadowed policy wins or loses by evaluation order |
Pārbaude ir vieta, kur lielākā daļa izmaiņu tiek slēgtas pārāk agri. Ping no vārtejas pierāda maz, jo vārteja sūta no sevis un bieži atbilst citai politikai nekā resursdators. Pingo no jaunā apakštīkla resursdatora, tad palaidiet lietojumprogrammu, kas izraisīja izmaiņas, un vērojiet skaitītājus, nevis statusa ikonu.
tcpdump -ni any host 192.168.60.10 and (esp or udp port 4500)
ip xfrm state
wg showUz politiku balstītā tunelī ip xfrm state skaitītājiem jāaug abos virzienos; plakani skaitītāji nozīmē, ka pakete ir maršrutēta, bet nav atlasīta. WireGuard wg show rāda pārraidi katrai pusei, un rokasspiediens ar nulli saņemtu baitu norāda uz tālās puses sarakstu vai tās atgriešanās maršrutu.
Pabeidziet, reģistrējot prefiksu, puses selektoru vai maršrutu, lēmumu par atgriešanās ceļu un ugunsmūra ierakstu kopā ar pārējo tuneļa inventarizāciju. Pēc tam restartējiet vienu vārteju un pārbaudiet vēlreiz: ar roku pievienots maršruts pazūd, un nākamajam cilvēkam tas nav jāatklāj no jauna.