Adresa VPN kundrejt qirasë DHCP në LAN: kush e cakton IP-në e tunelit?

Lidhni klientin dhe shikoni përshtatësin në vend të ikonës Wi-Fi. Një adresë si 10.80.0.14 mund të qëndrojë në një tunel ndërsa asnjë server DHCP në LAN-in e zyrës nuk e ka regjistruar kurrë atë qira. Procesi që zgjodhi numrin është ai që përcakton ku fillon zbulimi i problemit.

Në klient gjithçka duket njësoj: një adresë IPv4, një maskë, ndonjëherë një portë e paracaktuar. Dallimi shfaqet vetëm kur pyesni kush përgjigjet për atë adresë dhe kush mban një regjistër për të.

Lexoni adresën e tunelit nga ana e klientit

Windows e tregon dallimin nëse lexoni të gjithë bllokun dhe jo rreshtin e parë. ipconfig /all shtyp një përshkrim përshtatësi, një adresë fizike dhe një rresht DHCP. Një përshtatës telefoni PPP ose IKEv2 zakonisht raporton DHCP si të çaktivizuar, sepse lidhja e negocioi adresën gjatë telefonimit në vend që ta merrte me qira nga një server i LAN-it. Një përshtatës tuneli me DHCP të aktivizuar është i pazakontë dhe meriton një hetim më vete.

Linux i shpërndan të njëjtat informacione në dy mjete. ip -4 addr show dev tun0 jep adresën dhe gjatësinë e prefiksit. nmcli -f IP4 connection show work zbulon nëse vlera erdhi nga profili i lidhjes, nga një shkëmbim DHCP në lidhje apo nga një konfigurim i shtyrë. WireGuard është rasti më i qartë, sepse wg-quick zbaton rreshtin Address nga skedari i konfigurimit kur shfaqet ndërfaqja dhe asnjë palë nuk cakton asgjë në momentin e lidhjes.

Prefiksi thotë gjithashtu diçka. Një /32, ose një maskë prej 255.255.255.255, do të thotë që porta pret të rutojë drejt një adrese të vetme pritësi, ndërsa një maskë më e gjerë sugjeron një nënrrjet në lidhje diku pas tunelit.

Çfarë mbart ngarkesa e konfigurimit IKEv2

IKEv2 ka një mekanizëm të posaçëm për këtë punë. Ngarkesa e konfigurimit e përshkruar në RFC 7296, seksioni 3.15.1 mbart atribute si INTERNAL_IP4_ADDRESS, INTERNAL_IP4_NETMASK, INTERNAL_IP4_DNS dhe homologët e tyre IPv6. Klienti dërgon një atribut me vlerë me gjatësi zero kur nuk ka preferencë, dhe përgjigjësi kthen vlerën që dëshiron të përdoret. Ky shkëmbim zhvillohet brenda IKE_AUTH, tashmë i kriptuar, kështu që asnjë transmetim DHCP nuk e kalon kurrë tunelin.

Pasojnë dy gjëra. Së pari, adresën e zgjedh përgjigjësi ose çdo backend autorizimi që ai konsulton, prandaj një grup mund të jetojë në portë, në një përgjigje RADIUS ose në një hartëzim të ofruesit të identitetit. Së dyti, atributi DNS është i ndarë nga atributi i adresës. Marrja e 10.80.0.14 nuk thotë asgjë për atë se cili zgjidhës u kthye, ose nëse u kthye ndonjë.

Atributi i maskës së rrjetit është opsional në praktikë. Shumë vendosje kthejnë vetëm një adresë dhe e lënë klientin të instalojë një rrugë pritësi, prandaj i njëjti grup mund të duket si /32 në një klient dhe /24 në një tjetër.

Ku përplasen shtrirja DHCP e LAN-it dhe grupi VPN

Problemet nisin kur të dy caktuesit tregojnë të njëjtin interval. Një server DHCP për 10.20.30.0/24 nuk di asgjë për një grup VPN të konfiguruar për 10.20.30.128/25, kështu që asgjë nuk e pengon të japë 10.20.30.140 me qira një printeri ndërsa porta i jep të njëjtën adresë një klienti në distancë. Përplasja mbetet e heshtur për ditë dhe më pas shfaqet si një dublikatë e herëpashershme.

Një dizajn i rrugëzuar nga vendi në vend e shmang përplasjen nga vetë ndërtimi. Një pritës në degë mban adresën që i dha serveri lokal DHCP. Ndërfaqet e tunelit në të dy portat mbartin adresat e tyre të lidhjes, dhe tabela e rrugëzimit vendos si udhëtojnë paketat. Adresat e klientëve të qasjes në distancë janë kategoria e tretë dhe nuk duhet të përzihen me adresat e lidhjes së portës.

Ura e tunelit në LAN e heq atë ndarje. Nëse dizajni ka vërtet nevojë për një domen transmetimi, pika fundore e VPN duhet të marrë pjesë në të njëjtat vendime caktimi si serveri DHCP, përmes një releje ose një burimi të përbashkët autoritar, në vend që të lëshojë vetë adresa.

Verifikoni cili proces zotëron adresën

Provoni pronësinë përpara se të ndryshoni një shtrirje. Në klient, shënoni adresën dhe prefiksin. Në LAN, kërkoni në bazën e të dhënave të qirave. Në portë, listoni grupet që është konfiguruar të shpërndajë. Një adresë e gjetur në skedarin e qirave i përket një serveri DHCP, që do të thotë se tuneli është ura ose rele; një adresë e gjetur vetëm në grupin e portës i përket pikës fundore të tunelit.

# 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

Shënoni katër gjëra kur përgjigjja të jetë e qartë: cili komponent cakton adresën e klientit, cili interval është rezervuar për të, si arrin trafiku i kthimit në atë interval dhe cilat burime e pranojnë. Këto katër zëra e kthejnë një rresht përshtatësi virtual në një fakt operacional.

Përsëritni kontrollin për atributin DNS ndërsa jeni atje. Një grup që shpërndan adresa pa zgjidhës e lë klientin në DNS-në e tij lokal, që është një dështim i ndryshëm nga një grup që shpërndan një adresë që LAN-i tashmë e përdor.