Toisen aliverkon lisääminen sivustojen väliseen VPN:ään: kaksi polkua
Käytäntöperusteiset tunnelit tarvitsevat molemmille puolille sopivat valitsimet; reittipohjaiset tarvitsevat reitin. Valitse oikea polku ja korjaa ensin paluureitti.
Toisen aliverkon lisääminen toimivaan sivustojen väliseen tunneliin vie yhdessä mallissa viisi minuuttia ja toisessa lähes koko iltapäivän. Kun tunneli asentaa reitit nimeämillesi etuliitteille, lisäät reitin ja liikenne seuraa sitä. Kun se neuvottelee yhden kiinteän valitsinparin, uusi etuliite pysyy suojaamattomana, kunnes molemmat osapuolet sopivat vastaavasta parista. Kolme asiaa ratkaisee tapauksesi: mitä kunkin puolen kokoonpano todella kuvaa, supistuuko neuvoteltu liikenne pienimpään vastaavaan pariin ja kuka omistaa uuden alueen paluureitin.
Lue ydintä, älä tilamerkintää
Yhteydestä ilmoittava tunneli on asentanut vähintään yhden lapsiyhdistyksen, mutta ei välttämättä odottamaasi. Linuxissa ydin näyttää, mitä sovelletaan: ip xfrm policy luettelee valitsinparit ja swanctl --list-sas (tai vanhempi ipsec statusall) näyttää, mitä osapuolet neuvottelivat, mukaan lukien liikennevalitsimet kumpaankin suuntaan. Jos uusi etuliite ei ole kummassakaan, se on suojaamaton riippumatta siitä, mitä kokoonpanotiedosto sanoo.
Vertaa reittitaulukkoon. Reittipohjaisessa mallissa tunnelilaite on suojattujen etuliitteiden seuraava hyppy. Käytäntöperusteisessa mallissa ei usein ole erityistä reittiä etäaliverkolle, vain oletusreitti, koska käytäntö valitsee liikenteen eikä taulukko.
Käytäntöperusteiset tunnelit: molempien puolten on lueteltava uusi etuliite
strongSwanin termein valitsin on lapsikokoonpanon local_ts ja remote_ts kohdassa, leftsubnet ja rightsubnet seuraajissa. Uuden etuliitteen on näyttävä molemmilla puolilla peilatusti: minkä sivusto A nimeää paikalliseksi, sivusto B nimeää etäiseksi. Epäsuhta antaa harvoin puhtaan virheen. Puolet supistuvat leikkaukseen, vanha etuliite toimii ja vain uusi epäonnistuu hiljaa.
swanctl --load-conns
swanctl --initiate --child <child-name>
swanctl --list-sas
ip xfrm policypfSensessä tai OPNsensessä se tarkoittaa toista Phase 2 -merkintää, joka parittaa uuden paikallisen aliverkon uuteen etäiseen, ja sitten soveltamista. Säilytä vanha merkintä; korvaaminen siirtää alkuperäisen aliverkon sen sijaan että lisäisi. Jos olemassa oleva Phase 2 kattaa jo superverkon kuten 0.0.0.0/0 tai tiivistetyn alueen, älä lisää kapeampaa merkintää viereen: päällekkäiset valitsimet asentavat kilpailevat käytännöt ja arviointijärjestys ratkaisee voittajan.
IKEv1 tekee jokaisesta aliverkkoparista oman Phase 2:n, ja puoli, joka ottaa yhden parin vaihtoa kohden, pudottaa loput. IKEv2 voi kuljettaa useita valitsinpareja yhdessä lapsessa, mutta vain jos molemmat toteutukset hyväksyvät ne. Luettelo swanctl --list-sas:stä on totuus; kirjoittamasi on pyyntö.
Reittipohjaiset tunnelit: reitti on käytäntö
XFRM-rajapinta tai VTI-laite kuljettaa liikennettä reittitaulukon mukaan. Osoitat uuden etuliitteen laitteeseen molemmilla sivustoilla, ja rajapinnan muunnokseen sidottu tila astuu voimaan. Synkronoitavaa valitsinparia ei ole, siksi tämä malli skaalautuu paremmin aliverkkojen lisääntyessä. strongSwanin välitysohje käy läpi ytimen puolen tarkemmin.
ip route add 192.168.60.0/24 dev xfrm0
ip route get 192.168.60.10WireGuard vie ajatusta pidemmälle. AllowedIPs on samalla salauslupaluettelo ja wg-quick:n kautta reittitaulukon merkintä. Lisää etuliite vain toiselle puolelle, niin saat kättelyn, lähtevät paketit ja hiljaisuuden, koska etäpuoli pudottaa paketit, joiden lähde ei ole sen luettelossa. Muoto wg set korvaa koko luettelon, joten toista aiemmin toimineet etuliitteet tai katkaiset ne:
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 wg0Toinen komento ei ole valinnainen, kun käytit wg set:tä wg-quick:n sijaan. Ydin hyväksyy uuden luettelon heti, mutta mikään ei lisää sille reittiä, joten paikallisesti luotu liikenne lähtee yhä oletusyhdyskäytävän kautta. Se on yleisin syy siihen, että uusi WireGuard-aliverkko toimii tunnelin isännästä eikä kannettavasta.
Paluureitti pettää useammin kuin tunneli
Uuden etäaliverkon isäntien on lähetettävä vastaukset takaisin VPN-yhdyskäytävän kautta. Kun se yhdyskäytävä ei ole niiden oletusreititin, vastaus menee LAN-reitittimelle, joka joko pudottaa sen tai välittää sen internetiin yksityisellä lähdeosoitteella. Testaa etäpuolen isännästä, älä yhdyskäytävästä: ip route get 10.30.20.15 Linuxissa tai Find-NetRoute -RemoteIPAddress 10.30.20.15 PowerShellissä näyttää seuraavan hypyn, jota isäntä todella käyttää. Jos vastaus ei ole tunnelin päätepiste, lisää sinne staattinen reitti uudelle etuliitteelle.
Lähde-NAT sivustolla, jolta paluureitti puuttuu, on laillinen vaihtoehto ja tapa, jolla monet hub-and-spoke-järjestelyt välttävät jokaisen palvelimen koskettamisen. Käytä sitä myös uuteen etuliitteeseen kohdepuolen yhdyskäytävässä:
iptables -t nat -A POSTROUTING -s 10.30.20.0/24 -d 192.168.60.0/24 -j MASQUERADEHinta on todellinen. Etälokit lakkaavat näyttämästä yksittäisiä lähdeosoitteita ja alkuperäiseen aliverkkoon sidotut palomuurisäännöt kutistuvat yhdeksi säännöksi yhdyskäytävälle. Valitse se tarkoituksella, älä siksi että reitti puuttui.
Palomuurit ovat paluureitin toinen puoli. Vyöhykepohjaiset laitteet eivät laajenna olemassa olevan tunnelirajapinnan vyöhykettä automaattisesti uuteen aliverkkoon, eikä vanhalle etuliitteelle kirjoitettu sääntö täsmää. Lisää uusi aliverkko vyöhykkeeseen tai sääntöpakettiin molempiin suuntiin ennen kuin syytät IPseciä.
Ratkaise kolmella kysymyksellä ja varmista liikenteellä
Lyhyt versio: nimeääkö puolen kokoonpano etuliitteet (käytäntöperusteinen), vai reitittyykö liikenne rajapintaan (reittipohjainen)? Luettelevatko molemmat päät uuden etuliitteen? Onko uudesta aliverkosta paluureitti alkuperäiselle lähdealueelle?
| 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 |
Varmistus on kohta, jossa useimmat muutokset suljetaan liian aikaisin. Ping yhdyskäytävästä todistaa vähän, koska yhdyskäytävä lähettää itsestään ja osuu usein eri käytäntöön kuin isäntä. Pingaa uuden aliverkon isännästä, aja sitten muutoksen aiheuttanut sovellus ja seuraa laskureita, älä tilakuvaketta.
tcpdump -ni any host 192.168.60.10 and (esp or udp port 4500)
ip xfrm state
wg showKäytäntöperusteisessa tunnelissa ip xfrm state:n laskureiden pitäisi nousta molempiin suuntiin; tasaiset laskurit tarkoittavat, että paketti reitittyy mutta ei valikoidu. WireGuardissa wg show raportoi siirron puolittain, ja kättely ilman vastaanotettuja tavuja viittaa etäpuolen luetteloon tai sen paluureittiin.
Lopeta kirjaamalla etuliite, puolen valitsin tai reitti, paluureittipäätös ja palomuurimerkintä muun tunneliluettelon kanssa. Käynnistä sitten yksi yhdyskäytävä uudelleen ja testaa: käsin lisätty reitti katoaa, eikä seuraavan tarvitse löytää sitä uudelleen.