VPN-osoite vastaan LANin DHCP-vuokraus: kuka antaa tunnelin IP:n?

Yhdistä asiakas ja katso sovitinta Wi-Fi-kuvakkeen sijaan. Osoite kuten 10.80.0.14 voi olla tunnelissa, vaikka mikään toimiston LANin DHCP-palvelin ei ole koskaan kirjannut sitä vuokrausta. Se, mikä prosessi valitsi numeron, ratkaisee, mistä vianetsintä alkaa.

Asiakkaassa kaikki näyttää samalta: yksi IPv4-osoite, yksi peite, joskus oletusyhdyskäytävä. Ero tulee esiin vasta, kun kysyt kuka vastaa tästä osoitteesta ja kuka pitää siitä kirjaa.

Lue tunnelin osoite asiakkaan puolelta

Windows näyttää eron, jos luet koko lohkon etkä ensimmäistä riviä. ipconfig /all tulostaa sovittimen kuvauksen, fyysisen osoitteen ja DHCP-rivin. PPP- tai IKEv2-valintaissovitin ilmoittaa DHCP:n yleensä poissa käytöstä, koska yhteys neuvotteli osoitteensa valinnan aikana sen sijaan, että olisi vuokrannut sen LAN-palvelimelta. DHCP käytössä oleva tunnelisovitin on epätavallinen ja ansaitsee oman selvityksensä.

Linux jakaa saman tiedon kahdelle työkalulle. ip -4 addr show dev tun0 antaa osoitteen ja etuliitteen pituuden. nmcli -f IP4 connection show work paljastaa, tuliko arvo yhteysprofiilista, linkin DHCP-vaihdosta vai työnnetystä kokoonpanosta. WireGuard on selkein tapaus, koska wg-quick soveltaa kokoonpanotiedoston Address-riviä, kun liitäntä ilmestyy, eikä mikään vertaislaite jaa mitään yhdistämisen hetkellä.

Etuliite kertoo myös jotain. /32 tai 255.255.255.255-peite tarkoittaa, että yhdyskäytävä odottaa reitittävänsä yhteen isäntäosoitteeseen, kun taas leveämpi peite viittaa linkin aliverkkoon jossain tunnelin takana.

Mitä IKEv2-kokoonpanon hyötykuorma kuljettaa

IKEv2:lla on tätä työtä varten oma mekanismi. Kohdassa RFC 7296, jakso 3.15.1 kuvattu kokoonpanon hyötykuorma kuljettaa määritteitä kuten INTERNAL_IP4_ADDRESS, INTERNAL_IP4_NETMASK, INTERNAL_IP4_DNS ja niiden IPv6-vastineet. Asiakas lähettää nollamittaisen määritteen, kun sillä ei ole mieltymystä, ja vastaaja palauttaa arvon, jonka haluaa tulevan käytetyksi. Vaihto kulkee IKE_AUTHin sisällä jo salattuna, joten mikään DHCP-lähetys ei koskaan ylitä tunnelia.

Seuraa kaksi asiaa. Ensiksi osoitteen valitsee vastaaja tai mikä tahansa valtuutuspalvelu, jolta vastaaja kysyy, ja siksi allas voi sijaita yhdyskäytävällä, RADIUS-vastauksessa tai identiteettitarjoajan kartoituksessa. Toiseksi DNS-määrite on erillinen osoitemääritteestä. 10.80.0.14:n vastaanottaminen ei kerro mitään siitä, mikä nimipalvelin palasi tai palasiko yhtään.

Verkkopeitteen määrite on käytännössä valinnainen. Monet käyttöönotot palauttavat vain osoitteen ja antavat asiakkaan asentaa isäntäreitin, minkä vuoksi sama allas voi näyttää yhdellä asiakkaalla /32:lta ja toisella /24:lta.

Missä LANin DHCP-alue ja VPN-allas törmäävät

Ongelma alkaa, kun molemmat jakajat osoittavat samaan alueeseen. 10.20.30.0/24:n DHCP-palvelin ei tiedä mitään 10.20.30.128/25:lle määritetystä VPN-altaasta, joten mikään ei estä sitä vuokraamasta 10.20.30.140:a tulostimelle, kun yhdyskäytävä antaa saman osoitteen etäasiakkaalle. Törmäys pysyy päiviä hiljaisena ja tulee sitten esiin ajoittaisena kaksoiskappaleena.

Reititetty sivusto-sivusto-suunnittelu välttää törmäyksen rakenteellisesti. Sivukonttorin isäntä pitää osoitteen, jonka sen paikallinen DHCP-palvelin antoi. Molempien yhdyskäytävien tunneliliitännät kantavat omat linkkiosoitteensa, ja reititystaulu ratkaisee, miten paketit kulkevat. Etäkäyttöasiakkaiden osoitteet ovat kolmas luokka, eikä niitä pidä sekoittaa yhdyskäytävän linkkiosoitteisiin.

Tunnelin siltaaminen LANiin poistaa tämän erottelun. Jos suunnittelu todella tarvitsee yhden lähetysalueen, VPN-päätepisteen on osallistuttava samoihin jakopäätöksiin kuin DHCP-palvelin, releen tai yhteisen valtuutetun lähteen kautta, sen sijaan että se jakaisi osoitteita itse.

Todista, mikä prosessi omistaa osoitteen

Todista omistus ennen kuin muutat aluetta. Merkitse asiakkaalla osoite ja etuliite. Etsi LANissa vuokraustietokannasta. Listaa yhdyskäytävällä altaat, jotka se on määritetty jakamaan. Vuokraustiedostosta löytyvä osoite kuuluu DHCP-palvelimelle, eli tunneli on siltaattu tai releöity; vain yhdyskäytävän altaasta löytyvä osoite kuuluu tunnelin päätepisteelle.

# 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

Kirjaa neljä asiaa, kun vastaus on selvä: mikä komponentti jakaa asiakkaan osoitteen, mikä alue on varattu sille, miten paluuliikenne saavuttaa sen alueen ja mitkä resurssit hyväksyvät sen. Nämä neljä merkintää muuttavat virtuaalisen sovittimen rivin operatiiviseksi tosiasiaksi.

Toista tarkistus DNS-määritteelle, kun olet siellä. Allas, joka jakaa osoitteita ilman nimipalvelinta, jättää asiakkaan paikalliselle DNS:lleen, mikä on eri vika kuin allas, joka jakaa osoitteen, jota LAN jo käyttää.