VPN-adresse kontra DHCP-leige i LAN: kven tildeler tunnel-IP-en?

VPN-klienten din viser ei adresse som aldri dukkar opp i ei leigefil for LAN. Les klienten, IKEv2-nyttelasta og utvalet på gatewayen for å finne den rette tildelaren.

Kople til klienten og sjå på adapteren i staden for Wi-Fi-ikonet. Ei adresse som 10.80.0.14 kan liggje på ein tunnel sjølv om ingen DHCP-tenar i LAN-et på kontoret nokon gong har registrert den leiga. Prosessen som valde nummeret, avgjer kvar feilsøkinga byrjar.

På klienten ser alt likt ut: éi IPv4-adresse, éi maske, stundom ein standard gateway. Skilnaden syner seg først når du spør kven som svarar for den adressa, og kven som fører rekneskap med henne.

Les tunneladressa frå klientsida

Windows syner skilnaden om du les heile blokka og ikkje fyrste line. ipconfig /all skriv ut ei adapterbeskriving, ei fysisk adresse og ei DHCP-line. Ein PPP- eller IKEv2-oppringingsadapter melder vanlegvis DHCP som deaktivert, fordi sambandet forhandla adressa si under oppringinga i staden for å leige henne frå ein LAN-tenar. Ein tunneladapter med DHCP påslått er uvanleg og verd si eiga gransking.

Linux fordeler den same informasjonen på to verktøy. ip -4 addr show dev tun0 gir adressa og prefikslengda. nmcli -f IP4 connection show work avdekkjer om verdien kom frå sambandsprofilen, ei DHCP-utveksling på lenkja eller ein dytta konfigurasjon. WireGuard er det tydelegaste tilfellet, fordi wg-quick nyttar lina Address frå konfigurasjonsfila når grensesnittet dukkar opp, og ingen peer tildeler noko ved tilkopling.

Prefikset seier òg noko. Ein /32, eller ei maske på 255.255.255.255, tyder at gatewayen ventar å rute til éi vertsadresse, medan ei breiare maske antydar eit on-link-subnett ein stad bak tunnelen.

Kva IKEv2-konfigurasjonsnyttelasta ber

IKEv2 har ein eigen mekanisme for denne jobben. Konfigurasjonsnyttelasta som er skildra i RFC 7296, avsnitt 3.15.1, ber attributt som INTERNAL_IP4_ADDRESS, INTERNAL_IP4_NETMASK, INTERNAL_IP4_DNS og IPv6-motstykkja deira. Klienten sender eit attributt med null lengd når han ikkje har noka preferanse, og den svarande parten returnerer verdien han vil ha brukt. Den utvekslinga går inne i IKE_AUTH, alt kryptert, så inga DHCP-kringkasting kryssar nokon gong tunnelen.

To ting følgjer. Fyrst blir adressa vald av den svarande parten eller av kva autorisasjonsbakende han rådspør, og difor kan eit utval liggje på gatewayen, i eit RADIUS-svar eller i ein mapping hos ein identitetsleverandør. For det andre er DNS-attributtet skilt frå adresseattributtet. Å ta imot 10.80.0.14 seier ingenting om kva oppløysar som kom attende, eller om det i det heile kom nokon.

Nettmaskeattributtet er valfritt i praksis. Mange installasjonar returnerer berre ei adresse og lèt klienten installere ei vertsrute, og difor kan same utvalet sjå ut som ein /32 på éin klient og ein /24 på ein annan.

Der eit LAN-DHCP-område og eit VPN-utval kolliderer

Vanskane byrjar når begge tildelarane peikar på same område. Ein DHCP-tenar for 10.20.30.0/24 veit ingenting om eit VPN-utval sett opp for 10.20.30.128/25, så ingenting hindrar han i å leige ut 10.20.30.140 til ein skrivar medan gatewayen gir same adresse til ein fjernklient. Kollisjonen er stille i dagar og dukkar deretter opp som ein periodisk duplikat.

Eit ruta site-til-site-design unngår kollisjonen av seg sjølv. Ein vert i filialen held på adressa som den lokale DHCP-tenaren gav han. Tunnelgrensesnitta på begge gatewayane ber eigne lenkjeadresser, og rutetabellen avgjer korleis pakkane fer. Adressene til klientar for fjernåtkomst er ein tredje kategori og bør ikkje blandast med lenkjeadressene til gatewayen.

Å bru tunnelen inn i LAN-et fjernar den skilnaden. Om designet verkeleg treng eitt kringkastingsdomene, må VPN-endepunktet delta i dei same tildelingsvedtaka som DHCP-tenaren, via ein relay eller ei felles autoritativ kjelde, i staden for å gje ut adresser sjølv.

Prov eigarskapen før du endrar eit område

Prov eigarskapen før du endrar eit område. På klienten noterer du adressa og prefikset. I LAN-et søkjer du i leigedatabasen. På gatewayen listar du utvala han er sett opp til å dele ut. Ei adresse som finst i leigefila, høyrer til ein DHCP-tenar, som tyder at tunnelen er brua eller relaid; ei adresse som berre finst i utvalet til gatewayen, høyrer til tunnelendepunktet.

# 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

Noter fire ting når svaret er klart: kva komponent som tildeler klientadressa, kva område som er reservert for henne, korleis returtrafikken når det området, og kva ressursar som godtek henne. Dei fire oppføringane gjer ei line i ein virtuell adapter om til eit operativt faktum.

Gjenta kontrollen for DNS-attributtet medan du er der. Eit utval som deler ut adresser utan ein oppløysar, lèt klienten stå på sin lokale DNS, noko som er ein annan feil enn eit utval som deler ut ei adresse som LAN-et alt nyttar.

Relaterte artiklar