VPN helbidea ala LANeko DHCP errentamendua: nork esleitzen du tunelaren IPa?

Zure VPN bezeroak LANeko errentamendu fitxategian inoiz agertzen ez den helbidea erakusten du. Irakurri bezeroa, IKEv2 karga eta atebidearen pool-a benetako eslea aurkitzeko.

Konektatu bezeroa eta begiratu egokigailua Wi-Fi ikonoaren ordez. 10.80.0.14 bezalako helbide bat tunelean egon daiteke, bulegoko LANeko DHCP zerbitzariren inork sekula errentamendu hori erregistratu ez badu ere. Zenbakia zein prozesuk aukeratu zuen, horrek erabakitzen du non hasten den arazoen bilaketa.

Bezeroan dena berdin ikusten da: IPv4 helbide bat, maskara bat, batzuetan lehenetsitako atebidea. Aldea soilik agertzen da helbide horren erantzulea nor den eta haren erregistroa nor den galdetzean.

Irakurri tunelaren helbidea bezeroaren aldetik

Windowsek aldea erakusten du bloke osoa irakurtzen baduzu, lehen lerroa ez ezik. ipconfig /all egokigailuaren deskribapena, helbide fisikoa eta DHCP lerroa inprimatzen ditu. PPP edo IKEv2 markatze-egokigailuak DHCP desgaituta dagoela ematen du normalean, konexioak bere helbidea markatzean negoziatu zuelako, LAN zerbitzari batetik errentatu ordez. DHCP gaituta duen tunel egokigailua ezohikoa da eta bere horretan ikertzea merezi du.

Linuxek informazio bera bi tresnen artean banatzen du. ip -4 addr show dev tun0 helbidea eta aurrizkiaren luzera ematen ditu. nmcli -f IP4 connection show work balioa konexio profiletik, estekako DHCP truke batetik edo bultzatutako konfigurazio batetik etorri zen erakusten du. WireGuard da kasurik argiena, wg-quick interfazea agertzean konfigurazio fitxategiko Address lerroa aplikatzen duelako eta inongo parek ez duelako ezer esleitzen konektatzean.

Aurrizkiak ere zerbait esaten du. /32 batek, edo 255.255.255.255 maskara batek, atebideak host helbide bakarrera bideratzea espero duela esan nahi du, maskara zabalago batek tuneletik atzean nonbait estekako azpisare bat iradokitzen duen bitartean.

Zer darama IKEv2 konfigurazio kargak

IKEv2k lan honetarako mekanismo berezia du. RFC 7296, 3.15.1 atalean deskribatutako konfigurazio kargak INTERNAL_IP4_ADDRESS, INTERNAL_IP4_NETMASK, INTERNAL_IP4_DNS eta haien IPv6 baliokideak bezalako atributuak daramatza. Bezeroak zero luzerako balioa duen atributua bidaltzen du lehentasunik ez duenean, eta erantzuleak erabili nahi duen balioa itzultzen du. Truke hori IKE_AUTH barruan doa, jadanik zifratuta, beraz DHCP difusio batek ere ez du tunela zeharkatzen.

Ondorio bi datoz. Lehenik, erantzuleak edo hark kontsultatzen duen baimen backend edozeinek aukeratzen du helbidea, eta horregatik pool bat atebidean, RADIUS erantzun batean edo identitate hornitzaile baten mapatzean bizi daiteke. Bigarrenik, DNS atributua helbide atribututik bereizia dago. 10.80.0.14 jasotzeak ez du ezer esaten zein ebaztek itzuli zen edo itzuli ote zen.

Sare maskararen atributua hautazkoa da praktikan. Hedapen askok helbide bat baino ez dute itzultzen eta bezeroari host bide bat instalatzen uzten diote, eta horregatik pool bera /32 bezala ikus daiteke bezero batean eta /24 bezala bestean.

Non talka egiten dute LANeko DHCP eremuak eta VPN poolak

Arazoa bi esleitzaileek tarte berera seinalatzen dutenean hasten da. 10.20.30.0/24 rako DHCP zerbitzariak ez daki ezer 10.20.30.128/25 rako konfiguratutako VPN pool bati buruz, beraz ezerk ez dio galarazten 10.20.30.140 inprimagailu bati errentan ematea, atebideak helbide bera urruneko bezero bati ematen dion bitartean. Talka isilik geratzen da egunetan eta gero noizean behingo bikoiztu gisa azaleratzen da.

Gunez guneko diseinu bideratuak talka saihesten du eraikuntzaz. Suhkurtsaleko ostalari batek bertako DHCP zerbitzariak eman zion helbidea gordetzen du. Bi atebideen tunel interfazeek beren esteka helbideak daramatzate, eta bideratze taulak erabakitzen du nola bidaiatzen duten paketeek. Urruneko sarbideko bezeroen helbideak hirugarren kategoria dira eta ez lirateke atebidearen esteka helbideekin nahastu behar.

Tunela LANera zubikatzeak bereizketa hori kentzen du. Diseinuak benetan difusio domeinu bakarra behar badu, VPN amaierak DHCP zerbitzariaren esleipen erabaki berberetan parte hartu behar du, errele baten edo iturri autoritario partekatu baten bidez, helbideak bere kabuz jaulki ordez.

Egiaztatu zein prozesuk duen helbidea

Frogatu jabetza eremua aldatu aurretik. Bezeroan, hartu helbidea eta aurrizkia. LANean, bilatu errentamendu datu-basean. Atebidean, zerrendatu emateko konfiguratuta dituen poolak. Errentamendu fitxategian aurkitutako helbidea DHCP zerbitzari batena da, eta horrek tunela zubikatuta edo erreleztuta dagoela esan nahi du; atebidearen poolean bakarrik aurkitutako helbidea tunelaren amaierarena da.

# 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

Idatzi lau gauza erantzuna argi dagoenean: zein osagaik esleitzen duen bezeroaren helbidea, zein tarte dagoen horretarako gordeta, nola iristen den itzulera trafikoa tarte horretara eta zein baliabidek onartzen duten. Lau sarrera horiek egokigailu birtualeko lerro bat eragiketa egitate bihurtzen dute.

Errepikatu DNS atributuaren egiaztapena han zauden bitartean. Helbideak baina ebazlerik ematen ez duen pool batek bezeroa bere tokiko DNSan uzten du, eta hori LANak jada erabiltzen duen helbide bat ematen duen pool batekiko hutsegite desberdina da.

Erlazionatutako artikuluak