VPN-adreso kontraŭ LAN-DHCP-luo: kiu asignas la tunelan IP?

Via VPN-kliento montras adreson, kiu neniam aperas en LAN-lua dosiero. Legu la klienton, la IKEv2-ŝarĝon kaj la pordegan pulon por trovi la veran asignanton.

Konektu la klienton kaj rigardu la adaptilon anstataŭ la Wi-Fi-ikonon. Adreso kiel 10.80.0.14 povas sidi sur tunelo dum neniu DHCP-servilo en la oficeja LAN iam ajn registris tiun luon. La procezo, kiu elektis la numeron, decidas kie komenciĝas la problem-serĉado.

Ĉe la kliento ĉio aspektas same: unu IPv4-adreso, unu masko, foje implicita pordego. La diferenco aperas nur kiam vi demandas, kiu respondecas pri tiu adreso kaj kiu tenas registron pri ĝi.

Legu la tunelan adreson el la klienta flanko

Windows montras la diferencon se vi legas la tutan blokon anstataŭ la unuan linion. ipconfig /all presas adaptilan priskribon, fizikan adreson kaj DHCP-linion. PPP aŭ IKEv2-poŝa adaptilo kutime raportas DHCP kiel malŝaltita, ĉar la konekto intertraktis sian adreson dum la poŝado anstataŭ lui ĝin de LAN-servilo. Tunela adaptilo kun ŝaltita DHCP estas nekutima kaj indas apartan esploradon.

Linux disigas la saman informon inter du iloj. ip -4 addr show dev tun0 donas la adreson kaj la longon de la antaŭfikso. nmcli -f IP4 connection show work malkaŝas ĉu la valoro venis el la konekta profilo, el DHCP-interŝanĝo sur la ligilo, aŭ el puŝita agordo. WireGuard estas la plej klara kazo, ĉar wg-quick aplikas la linion Address el la agorda dosiero kiam la interfaco aperas, kaj neniu partnero asignas ion ĉe konekto.

La antaŭfikso ankaŭ diras ion. /32, aŭ masko de 255.255.255.255, signifas ke la pordego atendas enkursigi al unu gastigada adreso, dum pli larĝa masko sugestas sur-ligilan subreton ie malantaŭ la tunelo.

Kion portas la IKEv2-agorda ŝarĝo

IKEv2 havas dediĉitan meĥanismon por ĉi tiu tasko. La agorda ŝarĝo priskribita en RFC 7296, sekcio 3.15.1 portas atributojn kiel INTERNAL_IP4_ADDRESS, INTERNAL_IP4_NETMASK, INTERNAL_IP4_DNS kaj iliaj IPv6-ekvivalentoj. La kliento sendas atributon kun nula longo kiam ĝi havas neniun preferon, kaj la respondanto redonas la valoron kiun ĝi volas uzi. Tiu interŝanĝo veturas ene de IKE_AUTH, jam ĉifrita, do neniu DHCP-dissendo iam transiras la tunelon.

Du sekvoj sekvas. Unue, la adreson elektas la respondanto aŭ iu ajn rajtiga fono, kiun ĝi konsultas, kaj tial pulo povas loĝi sur la pordego, en RADIUS-respondo aŭ en mapado de identeca provizanto. Due, la DNS-atributo estas aparta de la adresa atributo. Ricevi 10.80.0.14 diras nenion pri tio, kiu solvilo revenis, aŭ ĉu iu ajn revenis.

La retmaska atributo estas praktike laŭvola. Multaj instaloj redonas nur adreson kaj lasas la klienton instali gastigadan vojon, kaj tial la sama pulo povas aspekti kiel /32 ĉe unu kliento kaj /24 ĉe alia.

Kie LAN-DHCP-amplekso kaj VPN-pulo kolizias

Problemoj komenciĝas kiam ambaŭ asignantoj montras al la sama intervalo. DHCP-servilo por 10.20.30.0/24 scias nenion pri VPN-pulo agordita por 10.20.30.128/25, do nenio malhelpas ĝin lui 10.20.30.140 al printilo dum la pordego donas la saman adreson al fora kliento. La kolizio restas silenta dum tagoj kaj poste aperas kiel intermita duplikato.

Enkursigita reteja-al-reteja dezajno evitas la kolizion per sia konstruo. Gastiganto en la filio konservas la adreson, kiun donis al ĝi la loka DHCP-servilo. La tunelaj interfacoj sur ambaŭ pordegoj portas siajn proprajn ligilajn adresojn, kaj la enkursiga tabelo decidas kiel vojaĝas pakoj. Adresoj de fora aliraj klientoj estas tria kategorio kaj ne miksiĝu kun la ligilaj adresoj de la pordego.

Ponti la tunelon sur la LAN forigas tiun apartigon. Se la dezajno vere bezonas unu dissendan domajnon, la VPN-finpunkto devas partopreni en la samaj asignaj decidoj kiel la DHCP-servilo, per relajso aŭ komuna aŭtoritata fonto, anstataŭ eldoni adresojn mem.

Kontrolu kiu procezo posedas la adreson

Pruvu la posedon antaŭ ol ŝanĝi amplekson. Ĉe la kliento, notu la adreson kaj antaŭfikson. En la LAN, serĉu en la lua datumbazo. Ĉe la pordego, listigu la pulojn kiujn ĝi estas agordita disdoni. Adreso trovita en la lua dosiero apartenas al DHCP-servilo, kio signifas ke la tunelo estas pontita aŭ relajsita; adreso trovita nur en la pordega pulo apartenas al la tunela finpunkto.

# 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

Notu kvar aferojn kiam la respondo klaras: kiu komponanto asignas la klientan adreson, kiu intervalo estas rezervita por ĝi, kiel revena trafiko atingas tiun intervalon, kaj kiuj rimedoj akceptas ĝin. Tiuj kvar eroj transformas virtualan adaptilan linion en operacian fakton.

Ripetu la kontrolon por la DNS-atributo dum vi estas tie. Pulo, kiu disdonas adresojn sed neniun solvilon, lasas la klienton sur ĝia loka DNS, kio estas alia fiasko ol pulo, kiu disdonas adreson kiun la LAN jam uzas.

Rilataj artikoloj