Dirprwyo rhagddodiad IPv6 ar draws VPN safle-i-safle: rhestr wirio

Codi'r twmnel yw'r hanner hawdd. Rwyf wedi gweld cyswllt safle-i-safle yn aros yn sefydledig am ddyddiau tra bo pob gwesteiwr ar y LAN bell yn cael distawrwydd yn ôl, oherwydd bod y rhagddodiad a ddirprwywyd y tu ôl i'r borth hwnnw wedi'i ffurfweddu ar ryngwyneb ond na chafodd ei lwybro i mewn i'r twmnel erioed. Roedd cyfeiriadau'r twmnel yn ateb pingiadau drwy'r amser, a dyna'n union pam na chymerodd neb sylw o'r rhagddodiad. Dyma'r drefn rwy'n ei gwirio pan fo rhagddodiad IPv6 a ddirprwywyd yn gorfod croesi VPN safle: y map rhagddodiadau, y detholwyr traffig, anfon ymlaen a'r wal dân, ac yna'r llwybr dychwelyd.

Ysgrifennwch y map rhagddodiadau cyn cyffwrdd â'r twmnel

Mae dirprwyo rhagddodiad yn ildio bloc i'r llwybrydd a ofynnodd amdano. Nid yw'n gosod llwybr ar y cymar, nid yw'n ymestyn y bloc hwnnw ar y cyswllt, ac nid yw'n dweud wrth y borth bell beth sy'n byw y tu ôl i'r llwybrydd sy'n gofyn. Eich gwaith chi yw'r tri pheth hynny, ac maent yn perthyn i gynllun cyfeiriadau cyn i unrhyw ffeil ffurfweddu newid.

Ar gyfer pob safle, cofnodwch y rhagddodiad a ddirprwywyd, y /64 sydd mewn gwirionedd yn cael ei defnyddio ar y LAN, cyfeiriadau'r twmnel a pherchennog pob llwybr. Mae'r darparwr yn dirprwyo 2001:db8:a1::/56 i safle A, sy'n gwasanaethu 2001:db8:a1:10::/64 ar ei LAN; mae safle B yn cadw 2001:db8:b2::/64. Os mai dim ond y /64 honno y mae safle A yn ei gwasanaethu, dylai'r ddau ben enwi 2001:db8:a1:10::/64 yn hytrach na'r /56 gyfan.

Mae dau gamgymeriad yn ymddangos bron bob tro. Y naill yw trin y rhagddodiad pell fel pe bai ar y cyswllt, ei bontio neu ei roi ar ryngwyneb y twmnel fel bod y borth yn ateb cais cymydog ar gyfer gwesteiwyr na all eu cyrraedd. Y llall yw hysbysu'r /56 gyfan pan mai dim ond un /64 sydd wedi'i ffurfweddu: mae'r tabl llwybrau yn honni bod y bloc yn gyrraeddadwy ac mae'r rhan fwyaf o'r cyfeiriadau yn disgyn i dwll du.

Cyfunwch ddetholwyr traffig y ddau ben â'r llwybrau

Mae IKEv2 a WireGuard ill dau yn gwrthod traffig anghyfatebol, yn ddigon tawel i'r twmnel edrych yn iach o hyd.

Yn strongSwan mae'r detholwyr yn amlwg. Ar safle A:

conn a-to-b
    left=2001:db8:ff::1
    leftsubnet=2001:db8:a1:10::/64
    right=2001:db8:ff::2
    rightsubnet=2001:db8:b2::/64
    auto=start

Mae conn safle B yn adlewyrchu'r ddwy isrwydwaith. Pan fyddant yn anghytuno, mae'r ymatebydd yn gwrthod y CHILD_SA gyda TS_UNACCEPTABLE, felly ni ddaw'r SA plentyn i fyny byth er bod yr IKE_SA wedi dod. Ar y ddau ochr rhaid i'r isrwydwaith a ffurfweddwyd fod yn hafal i'r hyn y mae'r cnewyllyn lleol yn ei lwybro tuag at y twmnel.

Mae WireGuard yn cario'r un wybodaeth yn AllowedIPs, gydag un tro: mae AllowedIPs yn hidlydd ffynhonnell wrth dderbyn yn ogystal â llwybr wrth anfon. Os yw cofnod cymar safle B ar gyfer safle A yn hepgor 2001:db8:a1:10::/64, mae pecynnau o safle A yn cyrraedd ar ysgwyd llaw dilys ac yn cael eu gollwng fel rhai nas caniateir. Mae hynny'n cynhyrchu'r patrwm cyfarwydd o ysgwyd llaw sy'n adnewyddu'n barhaus tra nad oes ateb byth yn gadael. Cymharwch y ddau ben gyda wg show wg0 allowed-ips. Ailwirio'r rhestr honno pryd bynnag y bydd y dirprwy yn newid; mae /64 hen yn cadw'r sesiwn i fyny ac yn gadael y rhagddodiad newydd yn anghyrraeddadwy.

Diystyrwch anfon ymlaen, y wal dân a'r MTU yn gyntaf

Cyn darllen unrhyw linell log arall, cadarnhewch fod y pyrth yn anfon ymlaen o gwbl. Rhaid i sysctl net.ipv6.conf.all.forwarding ddychwelyd 1 ar y ddau, wedi'i gymhwyso i ryngwynebau'r twmnel a'r LAN hefyd. Daw un trap ynghyd ag ef: unwaith y bydd anfon ymlaen ymlaen, mae rhyngwyneb ag accept_ra=1 yn stopio derbyn hysbysiadau llwybrydd gan y darparwr, felly gall y blwch golli ei lwybr diofyn i fyny'r llwybrau tra'n llwybro'n berffaith y tu mewn i'r twmnel. Gosodwch accept_ra=2 lle mae RA darparwr yn dal yn angenrheidiol.

Yna rhaid i reolau'r wal dân ganiatáu'r rhagddodiad yn y ddau gyfeiriad, a rhaid i ICMPv6 oroesi: nid yw darganfod cymydog, pecyn-rhy-fawr a chyrchfan-anghyraeddadwy yn ddewisol. Byddwch yn eu gollwng a bydd darganfod MTU y llwybr yn torri, gan roi cysylltiadau sy'n agor ac yna'n tagu ar yr ymateb mawr cyntaf. Mae pâr lleiaf o reolau'n edrych fel hyn:

nft add rule inet filter forward ip6 saddr 2001:db8:a1:10::/64 ip6 daddr 2001:db8:b2::/64 accept
nft add rule inet filter forward ip6 saddr 2001:db8:b2::/64 ip6 daddr 2001:db8:a1:10::/64 accept
nft add rule inet filter forward icmpv6 type { packet-too-big, nd-neighbor-solicit, nd-neighbor-advert } accept

Mae'r MTU y tu ôl i hynny. Mae twmnel yn crebachu'r MTU defnyddiadwy o dan 1500, ac mae IPv6 yn mynnu bod pob cyswllt yn cario o leiaf 1280. Mae pingiadau bach yn pasio, mae sesiwn SSH yn rhewi ar ffrwydrad mawr, ac mae /proc/net/snmp6 yn dangos negeseuon pecyn-rhy-fawr nad ydynt byth yn dychwelyd. Gosodwch MTU y twmnel yn eglur, neu glampiwch MSS TCP yn y tabl mangle, a gadewch i'r ICMPv6 sy'n adrodd yr MTU llai ddychwelyd.

Profwch y llwybr dychwelyd, nid cyfeiriad y twmnel

Y methiant sy'n costio'r mwyaf o amser yw llwybro unffordd. Mae pob porth yn llwybro'r rhagddodiad pell i'r twmnel, ond mae gwesteiwyr yn ateb drwy eu porth diofyn eu hunain oherwydd dyna lle mae eu /64 yn byw. Mae cael pecyn at y gyrchfan yn hanner llwybr yn unig.

Mae dau orchymyn yn setlo'r rhan fwyaf ohono. Ar safle A mae ip -6 route get 2001:db8:b2::53 from 2001:db8:a1:10::5 yn dangos pa ryngwyneb y byddai ateb o'r ffynhonnell honno'n ei ddefnyddio; rhedwch y gwiriad drych ar safle B. Yna cynhyrchwch draffig o westaiwr yn hytrach na'r borth a chymharwch y cyfrifwyr ar y ddau ben.

Os yw cais cymydog ar gyfer y rhagddodiad pell yn ymddangos ar y twmnel, mae'r rhagddodiad hwnnw ar y cyswllt yn rhywle na ddylai fod; trwsiwch hynny cyn addasu llwybrau. Mae Proxy NDP yn cwmpasu achosion lle mae pontio wirioneddol angenrheidiol, ac nid yw'n ddewis amgen i lwybr.

Cynlluniwch ar gyfer y rhagddodiad yn newid oddi tanoch

Mae dirprwyo rhagddodiad yn brydles rhwng y llwybrydd sy'n dirprwyo a'r llwybrydd sy'n gofyn, a gall adnewyddiad ddychwelyd bloc gwahanol: /56 wahanol ar ôl mudo darparwr, neu brydles fyrrach na'r amser y mae'r twmnel wedi bod i fyny. Mae pob man sy'n enwi'r hen ragddodiad yn mynd yn ddiweddar ar unwaith: llwybrau, detholwyr, AllowedIPs, rheolau'r wal dân, cofnodion DNS ac unrhyw fonitro sy'n codio cyfeiriadau llythrennol yn galed. Mae'r llif negeseuon yn RFC 8415.

Lle disgwylir i'r rhagddodiad symud, cadwch gynllun cyfeiriadau mewnol nad yw'n dibynnu arno a chyfieithwch ar y ffin. NPTv6 yw'r opsiwn di-wladwriaeth ac mae'n cadw polisi mewnol yn ddarllenadwy, ond cyfieithu rhagddodiadau ydyw, nid haen hud: rhaid i ffiniau /64 alinio, mae symiau gwirio yn cael eu haddasu, ac mae cymwysiadau sy'n mewnosod cyfeiriadau llythrennol yn dal i dorri. Os ydych yn cadw cyfeiriadau darparwr o'r dechrau i'r diwedd, cofnodwch ymddygiad y brydles a gweithdrefn newid yng nghynllun y cyfeiriadau.

Gorffennwch gyda phrawf sy'n goroesi amser: mae gwesteiwr a ganiateir ar bob LAN yn cyrraedd gwasanaeth ar y LAN arall, mae'r ateb yn dychwelyd drwy'r twmnel, ac mae'r un pâr yn dal i weithio ar ôl ailgychwyn y twmnel ac adnewyddu'r dirprwy. Os bydd y rhan olaf yn methu, mae'r dyluniad yn dibynnu ar gyflwr na fydd yn goroesi'r wythnos.