Cyfeiriad VPN yn erbyn les DHCP y LAN: pwy sy'n dyrannu IP y twnnel?

Cysylltwch y cleient a gweld yr addasydd yn lle'r eicon Wi-Fi. Gall cyfeiriad fel 10.80.0.14 fod ar dwnnel er nad oes unrhyw weinydd DHCP ar LAN y swyddfa erioed wedi cofnodi'r les honno. Y broses a ddewisodd y rhif sy'n penderfynu ble mae datrys y broblem yn dechrau.

Ar y cleient mae popeth yn edrych yr un fath: un cyfeiriad IPv4, un mwgwd, weithiau porth diofyn. Dim ond pan ofynnwch pwy sy'n ateb am y cyfeiriad hwnnw a phwy sy'n cadw cofnod ohono y daw'r gwahaniaeth i'r golwg.

Darllen cyfeiriad y twnnel o ochr y cleient

Mae Windows yn dangos y gwahaniaeth os darllenwch y bloc cyfan yn hytrach na'r llinell gyntaf. Mae ipconfig /all yn argraffu disgrifiad addasydd, cyfeiriad ffisegol a llinell DHCP. Yn nodweddiadol mae addasydd deialu PPP neu IKEv2 yn adrodd bod DHCP wedi'i analluogi, oherwydd bod y cysylltiad wedi trafod ei gyfeiriad yn ystod y deialu yn lle ei lesu o weinydd LAN. Mae addasydd twnnel â DHCP wedi'i alluogi yn anarferol ac yn werth ei ymchwilio ar ei ben ei hun.

Mae Linux yn rhannu'r un wybodaeth rhwng dau offeryn. Mae ip -4 addr show dev tun0 yn rhoi'r cyfeiriad a hyd y rhagddodiad. Mae nmcli -f IP4 connection show work yn datgelu a ddaeth y gwerth o broffil y cysylltiad, o gyfnewid DHCP ar y ddolen, neu o ffurfweddiad wedi'i wthio. WireGuard yw'r achos cliriaf, gan fod wg-quick yn cymhwyso llinell Address o'r ffeil ffurfweddu pan ymddangos y rhyngwyneb ac nad oes unrhyw gyfoed yn dyrannu dim ar adeg cysylltu.

Mae'r rhagddodiad yn dweud rhywbeth hefyd. Mae /32, neu fwgwd o 255.255.255.255, yn golygu bod y porth yn disgwyl llwybro i un cyfeiriad gwesteiwr, tra bod mwgwd ehangach yn awgrymu isrwydwaith ar-ddolen yn rhywle y tu ôl i'r twnnel.

Beth mae llwyth ffurfweddu IKEv2 yn ei gario

Mae gan IKEv2 fecanwaith pwrpasol ar gyfer y gwaith hwn. Mae'r llwyth ffurfweddu a ddisgrifir yn RFC 7296, adran 3.15.1 yn cario nodweddion fel INTERNAL_IP4_ADDRESS, INTERNAL_IP4_NETMASK, INTERNAL_IP4_DNS a'u cymheiriaid IPv6. Mae'r cleient yn anfon nodwedd â gwerth o hyd sero pan nad oes ganddo ffafriaeth, ac mae'r atebydd yn dychwelyd y gwerth y mae am iddo gael ei ddefnyddio. Mae'r gyfnewid honno'n teithio y tu mewn i IKE_AUTH, eisoes wedi'i hamgryptio, felly nid oes unrhyw ddarllediad DHCP yn croesi'r twnnel.

Daw dau ganlyniad. Yn gyntaf, yr atebydd sy'n dewis y cyfeiriad, neu ba bynnag gefnlen awdurdodi y mae'n ymgynghori â hi, a dyna pam y gall cronfa fyw ar y porth, mewn ateb RADIUS, neu ym mapiau darparwr hunaniaeth. Yn ail, mae'r nodwedd DNS ar wahân i nodwedd y cyfeiriad. Nid yw derbyn 10.80.0.14 yn dweud dim am ba ddatryswr a ddaeth yn ôl, nac a ddaeth un o gwbl.

Mae nodwedd y mwgwd rhwydwaith yn ddewisol yn ymarferol. Mae llawer o osodiadau'n dychwelyd cyfeiriad yn unig ac yn gadael i'r cleient osod llwybr gwesteiwr, a dyna pam y gall yr un grŵp edrych fel /32 ar un cleient a /24 ar un arall.

Lle mae cwmpas DHCP y LAN a chronfa VPN yn gwrthdaro

Mae trafferth yn dechrau pan fo'r ddau ddyrannwr yn pwyntio at yr un amrediad. Nid yw gweinydd DHCP ar gyfer 10.20.30.0/24 yn gwybod dim am grŵp VPN wedi'i ffurfweddu ar gyfer 10.20.30.128/25, felly nid oes dim yn ei rwystro rhag lesu 10.20.30.140 i argraffydd tra bod y porth yn rhoi'r un cyfeiriad i gleient o bell. Mae'r gwrthdaro'n aros yn dawel am ddyddiau ac yna'n dod i'r wyneb fel dyblyg achlysurol.

Mae dyluniad llwybredig safle-i-safle yn osgoi'r gwrthdaro drwy ei adeiladwaith. Mae gwesteiwr yn y gangen yn cadw'r cyfeiriad a roddodd ei weinydd DHCP lleol iddo. Mae rhyngwynebau twnnel y ddau borth yn cario eu cyfeiriadau dolen eu hunain, a'r tabl llwybro sy'n penderfynu sut mae pecynnau'n teithio. Mae cyfeiriadau cleientiaid mynediad o bell yn drydedd gategori ac ni ddylid eu cymysgu â chyfeiriadau dolen y porth.

Mae pontio'r twnnel i'r LAN yn dileu'r gwahanu hwnnw. Os oes gwir angen un parth darlledu ar y dyluniad, rhaid i bwynt terfyn y VPN gymryd rhan yn yr un penderfyniadau dyrannu â'r gweinydd DHCP, drwy ataliad neu ffynhonnell awdurdodol a rennir, yn lle cyhoeddi cyfeiriadau ar ei ben ei hun.

Gwirio pa broses sy'n berchen ar y cyfeiriad

Profwch y perchnogaeth cyn newid cwmpas. Ar y cleient, cofnodwch y cyfeiriad a'r rhagddodiad. Ar y LAN, chwiliwch y gronfa ddata les. Ar y porth, rhestrwch y cronfeydd y mae wedi'i ffurfweddu i'w dosbarthu. Cyfeiriad a geir yn y ffeil les sy'n perthyn i weinydd DHCP, sy'n golygu bod y twnnel wedi'i bontio neu wedi'i ategu; cyfeiriad a geir yn unig yng nghronfa'r porth sy'n perthyn i bwynt terfyn y twnnel.

# client: address and prefix on the tunnel interface
ip -4 addr show dev tun0

# LAN DHCP server: is this address leased to anyone?
grep -c '10.80.0.14' /var/lib/dhcp/dhcpd.leases

# gateway: pools that remote-access clients draw from
sudo swanctl --list-pools

Cofnodwch bedair peth unwaith y bydd yr ateb yn glir: pa gydran sy'n dyrannu cyfeiriad y cleient, pa amrediad sydd wedi'i gadw ar ei gyfer, sut mae'r traffig dychwelyd yn cyrraedd yr amrediad hwnnw, a pha adnoddau sy'n ei dderbyn. Mae'r pedwar cofnod hynny'n troi llinell addasydd rhithwir yn ffaith weithredol.

Ailadroddwch y gwiriad ar gyfer y nodwedd DNS tra byddwch yno. Mae cronfa sy'n dosbarthu cyfeiriadau heb ddatryswr yn gadael y cleient ar ei DNS lleol, sy'n fethiant gwahanol i gronfa sy'n dosbarthu cyfeiriad y mae'r LAN eisoes yn ei ddefnyddio.