Address ng VPN kumpara sa DHCP lease ng LAN: sino ang nagtatalaga ng IP ng tunnel?

Ikonekta ang client at tingnan ang adapter sa halip na ang Wi-Fi icon. Ang address na gaya ng 10.80.0.14 ay maaaring nasa isang tunnel kahit walang DHCP server sa LAN ng opisina ang nakatala ng lease na iyon. Ang prosesong pumili ng numero ang nagpapasya kung saan magsisimula ang pag-troubleshoot.

Sa client, magkapareho ang lahat: isang IPv4 address, isang mask, kung minsan ay default gateway. Lumilitaw lamang ang pagkakaiba kapag tinanong mo kung sino ang sumasagot para sa address na iyon at sino ang nagtatala nito.

Basahin ang address ng tunnel mula sa panig ng client

Ipinapakita ng Windows ang pagkakaiba kung babasahin mo ang buong block at hindi ang unang linya. Nagpi-print ang ipconfig /all ng paglalarawan ng adapter, pisikal na address at linya ng DHCP. Karaniwang iniuulat ng PPP o IKEv2 dial-up adapter na naka-disable ang DHCP, dahil nakipag-usap ang koneksyon para sa address nito habang nagda-dial sa halip na umupa mula sa isang LAN server. Ang tunnel adapter na may DHCP na naka-enable ay hindi karaniwan at karapat-dapat sa hiwalay na pagsisiyasat.

Hinahati ng Linux ang parehong impormasyon sa dalawang tool. Ibinibigay ng ip -4 addr show dev tun0 ang address at haba ng prefix. Isinisiwalat ng nmcli -f IP4 connection show work kung ang halaga ay nagmula sa profile ng koneksyon, sa palitan ng DHCP sa link, o sa itinulak na configuration. Ang WireGuard ang pinakamalinaw na kaso, dahil inilalapat ng wg-quick ang linyang Address mula sa configuration file kapag lumitaw ang interface at walang peer na nagtatalaga ng anuman sa oras ng pagkonekta.

May sinasabi rin ang prefix. Ang /32, o mask na 255.255.255.255, ay nangangahulugang inaasahan ng gateway na mag-ruta patungo sa isang host address, samantalang ang mas malawak na mask ay nagmumungkahi ng on-link subnet sa isang lugar sa likod ng tunnel.

Ano ang dinadala ng IKEv2 configuration payload

May nakalaang mekanismo ang IKEv2 para sa gawaing ito. Ang configuration payload na inilarawan sa RFC 7296, seksyon 3.15.1 ay nagdadala ng mga attribute gaya ng INTERNAL_IP4_ADDRESS, INTERNAL_IP4_NETMASK, INTERNAL_IP4_DNS at ang kanilang mga katapat na IPv6. Nagpapadala ang client ng attribute na may haba na zero kapag wala itong kagustuhan, at ibinabalik ng sumasagot ang halagang nais nitong gamitin. Dumadaan ang palitang iyon sa loob ng IKE_AUTH, naka-encrypt na, kaya walang DHCP broadcast ang tumatawid sa tunnel.

May dalawang kahihinatnan. Una, ang address ay pinipili ng sumasagot o ng anumang authorization backend na kinukunsulta nito, kaya maaaring manirahan ang pool sa gateway, sa isang RADIUS reply o sa isang mapping ng identity provider. Ikalawa, ang DNS attribute ay hiwalay sa address attribute. Ang pagtanggap ng 10.80.0.14 ay walang sinasabi tungkol sa kung aling resolver ang bumalik, o kung may bumalik man.

Ang netmask attribute ay opsyonal sa praktika. Maraming deployment ang nagbabalik lamang ng address at hinahayaang i-install ng client ang isang host route, kaya ang parehong pool ay maaaring magmukhang /32 sa isang client at /24 sa iba.

Kung saan nagbabanggaan ang DHCP scope ng LAN at pool ng VPN

Nagsisimula ang problema kapag ang dalawang tagapagtala ay tumuturo sa parehong saklaw. Ang DHCP server para sa 10.20.30.0/24 ay walang alam tungkol sa pool ng VPN na naka-configure para sa 10.20.30.128/25, kaya walang pumipigil dito na i-lease ang 10.20.30.140 sa isang printer habang ibinibigay ng gateway ang parehong address sa isang remote client. Tahimik ang banggaan nang maraming araw at pagkatapos ay lumilitaw bilang paminsan-minsang duplicate.

Iniiwasan ng routed na site-to-site na disenyo ang banggaan dahil sa sarili nitong pagkakabuo. Ang host sa sangay ay nagpapanatili ng address na ibinigay ng lokal na DHCP server. Ang mga tunnel interface sa dalawang gateway ay may kani-kanilang link address, at ang routing table ang nagpapasya kung paano naglalakbay ang mga packet. Ang mga address ng remote access client ay ikatlong kategorya at hindi dapat ihalo sa link address ng gateway.

Ang pag-bridge ng tunnel sa LAN ay nag-aalis ng paghihiwalay na iyon. Kung talagang kailangan ng disenyo ng isang broadcast domain, ang VPN endpoint ay dapat makibahagi sa parehong mga desisyon sa pagtatalaga gaya ng DHCP server, sa pamamagitan ng relay o pinagsamang authoritative source, sa halip na maglabas mismo ng mga address.

Tiyakin kung aling proseso ang may-ari ng address

Patunayan ang pagmamay-ari bago baguhin ang isang scope. Sa client, itala ang address at prefix. Sa LAN, maghanap sa lease database. Sa gateway, ilista ang mga pool na naka-configure nitong ibigay. Ang address na matatagpuan sa lease file ay pag-aari ng isang DHCP server, ibig sabihin ang tunnel ay naka-bridge o naka-relay; ang address na matatagpuan lamang sa pool ng gateway ay pag-aari ng tunnel endpoint.

# 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

Itala ang apat na bagay kapag malinaw na ang sagot: aling component ang nagtatalaga ng client address, aling saklaw ang nakalaan para dito, paano nararating ng return traffic ang saklaw na iyon at aling mga resource ang tumatanggap nito. Ang apat na entry na iyon ay ginagawang operational fact ang isang linya ng virtual adapter.

Ulitin ang pagsusuri para sa DNS attribute habang naroon ka. Ang pool na nagbibigay ng address ngunit walang resolver ay iniiwan ang client sa lokal nitong DNS, na ibang pagkabigo kaysa sa pool na nagbibigay ng address na ginagamit na ng LAN.