Ychwanegu ail is-rwydwaith at VPN safle-i-safle: dau lwybr
Mae twneli sy’n seiliedig ar bolisi angen detholwyr cyfatebol ar y ddau ben; mae’r rhai sy’n seiliedig ar lwybr angen llwybr. Dewiswch y llwybr iawn a thrwsiwch y llwybr dychwelyd yn gyntaf.
Mae ychwanegu ail is-rwydwaith at dwnel safle-i-safle sy’n gweithio yn cymryd pum munud mewn un dyluniad a bron y prynhawn cyfan yn y llall. Pan fydd y twnel yn gosod llwybrau ar gyfer y rhagddodiaid a enwch, rydych yn ychwanegu llwybr ac mae’r traffig yn ei ddilyn. Pan fydd yn negodi un pâr detholydd sefydlog, mae’r rhagddodiad newydd yn aros heb ei amddiffyn nes bod y ddau ben yn cytuno ar bâr cyfatebol. Mae tri pheth yn penderfynu eich achos: beth mae cyfluniad pob pen yn ei ddisgrifio mewn gwirionedd, a yw’r traffig a negodwyd yn culhau i’r pâr cyfatebol lleiaf, a phwy sy’n berchen ar y llwybr dychwelyd ar gyfer yr ystod newydd.
Darllenwch y cnewyllyn, nid label y statws
Mae twnel sy’n adrodd ei fod wedi cysylltu wedi gosod o leiaf un cymdeithas blentyn, ond nid o reidrwydd yr un rydych yn ei ddisgwyl. Ar Linux mae’r cnewyllyn yn dangos beth sy’n cael ei gymhwyso: mae ip xfrm policy yn rhestr y parau detholydd, ac mae swanctl --list-sas (neu’r hen ipsec statusall) yn dangos beth a negodwyd, gan gynnwys y detholwyr traffig ym mhob cyfeiriad. Os nad yw’r rhagddodiad newydd yn y naill na’r llall, mae heb ei amddiffyn waeth beth mae’r ffeil gyfluniad yn ei ddweud.
Cymharwch hynny â’r tabl llwybrau. Mewn trefniant sy’n seiliedig ar lwybr, dyfais y twnel yw’r naid nesaf ar gyfer y rhagddodiaid a amddiffynnir. Yn aml nid oes gan drefniant sy’n seiliedig ar bolisi lwybr penodol ar gyfer yr is-rwydwaith bell, dim ond y llwybr diofyn, oherwydd y polisi sy’n dewis traffig, nid y tabl.
Twneli sy’n seiliedig ar bolisi: rhaid i’r ddau ben restru’r rhagddodiad newydd
Ym mhtermau strongSwan mae’r detholydd yn byw yn local_ts a remote_ts o dan y cyfluniad plentyn, olynwyr leftsubnet a rightsubnet. Rhaid i’r rhagddodiad newydd ymddangos ar y ddau ben fel drych: yr hyn y mae safle A yn ei alw’n lleol, mae safle B yn ei alw’n bell. Anaml y mae anghytundeb yn rhoi gwall glân. Mae’r ddau ben yn culhau i’r croestoriad, mae’r hen ragddodiad yn parhau i weithio a’r un newydd yn methu’n dawel.
swanctl --load-conns
swanctl --initiate --child <child-name>
swanctl --list-sas
ip xfrm policy
Ar pfSense neu OPNsense mae hynny’n golygu ail gofnod Phase 2 sy’n paru’r is-rwydwaith lleol newydd â’r un bell newydd, ac yna cymhwyso. Cadwch yr hen gofnod; mae ei ddisodli yn symud yr is-rwydwaith wreiddiol yn hytrach nag ychwanegu. Os yw Phase 2 sy’n bodoli eisoes yn cwmpasu uwch-rwydwaith fel 0.0.0.0/0 neu ystod gryno, peidiwch ag ychwanegu cofnod culach wrth ei ymyl: mae detholwyr sy’n gorgyffwrdd yn gosod polisïau cystadleuol a’r drefn werthuso sy’n penderfynu pwy sy’n ennill.
Mae IKEv1 yn gwneud pob pâr is-rwydwaith yn Phase 2 ei hun, ac mae pen sy’n cymryd un pâr y cyfnewid yn gollwng y gweddill. Gall IKEv2 gario sawl pâr detholydd mewn un plentyn, ond dim ond os yw’r ddau weithrediad yn eu derbyn. Y rhestr o swanctl --list-sas yw’r gwirionedd; yr hyn a deipiwyd gennych yw cais.
Twneli sy’n seiliedig ar lwybr: y llwybr yw’r polisi
Mae rhyngwyneb XFRM neu ddyfais VTI yn cario traffig yn ôl y tabl llwybrau. Rydych yn cyfeirio’r rhagddodiad newydd at y ddyfais yn y ddau safle ac mae’r cyflwr sy’n rhwym wrth drawsffurfiad y rhyngwyneb yn gymwys. Nid oes pâr detholydd i’w gydamseru, a dyna pam mae’r dyluniad hwn yn graddio’n well wrth i is-rwydweithiau luosi. Mae canllaw anfon strongSwan yn mynd trwy ochr y cnewyllyn yn fanwl.
ip route add 192.168.60.0/24 dev xfrm0
ip route get 192.168.60.10
Mae WireGuard yn mynd â’r syniad ymhellach. AllowedIPs yw’r rhestr ganiatáu cryptograffig ar yr un pryd ac, drwy wg-quick, y cofnod yn y tabl llwybrau. Ychwanegwch y rhagddodiad ar un pen yn unig a chewch ysgwyd llaw, pecynnau allan a distawrwydd, oherwydd mae’r ochr bell yn gollwng pecynnau nad yw eu ffynhonnell ar ei rhestr. Mae ffurf wg set yn disodli’r rhestr gyfan, felly ailadroddwch y rhagddodiaid a oedd yn gweithio neu byddwch yn eu torri i ffwrdd:
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
Nid yw’r ail orchymyn yn ddewisol pan ddefnyddiwyd wg set yn lle wg-quick. Mae’r cnewyllyn yn derbyn y rhestr newydd ar unwaith, ond nid oes unrhyw beth yn ychwanegu llwybr ar ei chyfer, felly mae traffig a gynhyrchir yn lleol yn dal i adael drwy’r giât ddiofyn. Dyma’r rheswm mwyaf cyffredin pam mae is-rwydwaith WireGuard newydd yn gweithio o westeiwr y twnel ac nid o liniadur.
Mae’r llwybr dychwelyd yn methu’n amlach na’r twnel
Rhaid i westeiwyr ar yr is-rwydwaith bell newydd anfon atebion yn ôl drwy giât y VPN. Pan nad yw’r giât honno’n llwybrydd diofyn iddynt, mae’r ateb yn mynd i lwybrydd y LAN, sy’n ei ollwng neu’n ei anfon i’r rhyngrwyd gyda chyfeiriad ffynhonnell preifat. Profwch o westeiwr ar yr ochr bell yn hytrach nag o’r giât: mae ip route get 10.30.20.15 ar Linux neu Find-NetRoute -RemoteIPAddress 10.30.20.15 yn PowerShell yn dangos y naid nesaf y bydd y gwesteiwr yn ei defnyddio mewn gwirionedd. Os nad yr ateb yw pen y twnel, ychwanegwch lwybr statig ar ei gyfer yno.
Mae NAT ffynhonnell yn y safle sydd heb y llwybr dychwelyd yn ddewis amgen dilys a dyna sut mae llawer o drefniadau hub-and-spoke yn osgoi cyffwrdd pob gweinydd. Cymhwyswch ef at y rhagddodiad newydd ar giât yr ochr gyrchfan hefyd:
iptables -t nat -A POSTROUTING -s 10.30.20.0/24 -d 192.168.60.0/24 -j MASQUERADE
Mae’r gost yn real. Mae cofnodion pell yn stopio dangos cyfeiriadau ffynhonnell unigol, ac mae rheolau mur gwarchod sy’n seiliedig ar yr is-rwydwaith wreiddiol yn cwympo i un rheol ar gyfer y giât. Dewiswch hynny’n fwriadol, nid oherwydd bod llwybr ar goll.
Muriau gwarchod yw hanner arall y llwybr dychwelyd. Nid yw dyfeisiau sy’n seiliedig ar barthau yn ymestyn parth rhyngwyneb twnel sy’n bodoli at is-rwydwaith newydd yn awtomatig, ac ni fydd rheol a ysgrifennwyd ar gyfer yr hen ragddodiad yn cyfateb. Ychwanegwch yr is-rwydwaith newydd at y parth neu’r pâr rheolau yn y ddau gyfeiriad cyn beio IPsec.
Penderfynwch â thri chwestiwn, yna dilyswch â thraffig
Y fersiwn gyflym: a yw cyfluniad y pen yn enwi rhagddodiaid (seiliedig ar bolisi), neu a yw traffig yn llwybro i ryngwyneb (seiliedig ar lwybr)? A yw’r ddau ben yn rhestru’r rhagddodiad newydd? A oes llwybr yn ôl o’r is-rwydwaith newydd i’r ystod ffynhonnell wreiddiol?
| 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 |
Dilysu yw lle mae’r rhan fwyaf o newidiadau’n cael eu cau’n rhy gynnar. Ychydig mae ping o’r giât yn ei brofi, oherwydd mae’r giât yn anfon o honi ei hun ac yn aml yn cyfateb i bolisi gwahanol i un gwesteiwr. Pingiwch o westeiwr ar yr is-rwydwaith newydd, yna rhedegwch y rhaglen a ysgogodd y newid, a gwyliwch y cyfrifwyr yn hytrach nag eicon statws.
tcpdump -ni any host 192.168.60.10 and (esp or udp port 4500)
ip xfrm state
wg show
Ar dwnel sy’n seiliedig ar bolisi dylai cyfrifwyr ip xfrm state godi yn y ddau gyfeiriad; mae cyfrifwyr gwastad yn golygu bod y pecyn wedi’i lwybro ond heb ei ddewis. Ar WireGuard mae wg show yn adrodd trosglwyddiad fesul pen, ac mae ysgwyd llaw gyda sero beit a dderbyniwyd yn cyfeirio at restr ganiatáu’r ochr bell neu ei llwybr dychwelyd.
Gorffennwch drwy gofnodi’r rhagddodiad, detholydd neu lwybr y pen, y penderfyniad ar y llwybr dychwelyd a’r cofnod mur gwarchod gyda gweddill rhestr y twnel. Yna ailgychwynnwch un giât a phrofwch eto: mae llwybr a ychwanegwyd â llaw yn diflannu, ac ni ddylai’r person nesaf orfod ailddarganfod hynny.