VPN-aadress versus LAN-i DHCP-rendileping: kes määrab tunnelile IP?

Ühendage klient ja vaadake adapterit, mitte Wi-Fi ikooni. Selline aadress nagu 10.80.0.14 võib olla tunnelil, kuigi ükski kontori LAN-i DHCP-server pole seda rendilepingut kunagi registreerinud. See, milline protsess numbri valis, määrab, kust tõrkeotsing algab.

Kliendis näeb kõik ühesugune välja: üks IPv4-aadress, üks mask, mõnikord vaikelüüs. Erinevus ilmneb alles siis, kui küsida, kes selle aadressi eest vastutab ja kes selle kohta arvestust peab.

Lugege tunneli aadressi kliendi poolelt

Windows näitab erinevust, kui loete tervet plokki, mitte esimest rida. ipconfig /all trükib adapteri kirjelduse, füüsilise aadressi ja DHCP-rea. PPP- või IKEv2-sissehelistamisadapter teatab DHCP tavaliselt keelatuna, sest ühendus leppis aadressi kokku sissehelistamise ajal, mitte ei rentinud seda LAN-serverist. DHCP-ga tunnelil adapter on ebatavaline ja väärib eraldi uurimist.

Linux jagab sama teabe kahe tööriista vahel. ip -4 addr show dev tun0 annab aadressi ja prefiksi pikkuse. nmcli -f IP4 connection show work näitab, kas väärtus tuli ühenduse profiilist, lingi DHCP-vahetusest või lükatud konfiguratsioonist. WireGuard on kõige selgem juhtum, sest wg-quick rakendab liidese ilmumisel konfiguratsioonifailist pärinevat rida Address ja ükski partner ei määra ühendamise hetkel midagi.

Prefiks ütleb ka midagi. /32 või mask 255.255.255.255 tähendab, et lüüs ootab marsruutimist ühele hosti aadressile, laiem mask aga viitab lingil olevale alamvõrgule kuskil tunnelist tagapool.

Mida IKEv2 konfiguratsiooni kasulik koormus kannab

IKEv2-l on selle töö jaoks eraldi mehhanism. Jaotises RFC 7296, punkt 3.15.1 kirjeldatud konfiguratsiooni kasulik koormus kannab atribuute nagu INTERNAL_IP4_ADDRESS, INTERNAL_IP4_NETMASK, INTERNAL_IP4_DNS ja nende IPv6-vasteid. Klient saadab nullpikkusega atribuudi, kui tal eelistust pole, ja vastaja tagastab väärtuse, mida ta soovib kasutada. See vahetus käib IKE_AUTH-i sees, juba krüpteeritult, nii et ükski DHCP-teade ei ületa kunagi tunnelit.

Sellest tuleneb kaks tagajärge. Esiteks valib aadressi vastaja või ükskõik milline volitamise taustsüsteem, keda vastaja küsib, ja seetõttu võib pool asuda lüüsil, RADIUS-vastuses või identiteedipakkuja vastenduses. Teiseks on DNS-atribuut aadressiatribuudist eraldi. 10.80.0.14 saamine ei ütle midagi selle kohta, milline nimeresolver tagasi tuli või kas üldse tuli.

Võrgumaski atribuut on praktikas valikuline. Paljud juurutused tagastavad ainult aadressi ja lasevad kliendil paigaldada hosti marsruudi, mistõttu sama pool võib ühes kliendis paista /32 ja teises /24.

Kus LAN-i DHCP-vahemik ja VPN-i pool kokku põrkavad

Probleem algab siis, kui mõlemad määrajad osutavad samale vahemikule. 10.20.30.0/24 jaoks mõeldud DHCP-server ei tea midagi 10.20.30.128/25 jaoks seadistatud VPN-i poolist, nii et miski ei takista tal anda 10.20.30.140 printerile rendile, samal ajal kui lüüs annab sama aadressi kaugkliendile. Kokkupõrge püsib päevi märkamatu ja tuleb siis esile aeg-ajalt korduva aadressina.

Marsruuditud saidi-saiti lahendus väldib kokkupõrget juba konstruktsiooni tõttu. Harukontori host säilitab aadressi, mille andis talle kohalik DHCP-server. Mõlema lüüsi tunneliliidesed kannavad oma lingiaadresse ja marsruutimistabel otsustab, kuidas paketid liiguvad. Kaugjuurdepääsu klientide aadressid on kolmas kategooria ja neid ei tohiks segada lüüsi lingiaadressidega.

Tunneli sillutamine LAN-i peale kaotab selle eralduse. Kui lahendus vajab tõesti ühte ringhäälingudomeeni, peab VPN-i lõpp-punkt osalema samades määramisotsustes nagu DHCP-server, relee või ühise autoriteetse allika kaudu, mitte väljastama aadresse ise.

Kontrollige, millisele protsessile aadress kuulub

Tõestage omandiõigus enne, kui muudate vahemikku. Kliendis kirjutage üles aadress ja prefiks. LAN-is otsige rendilepete andmebaasist. Lüüsil loetlege poolid, mille väljastamiseks see on seadistatud. Rendilepete failist leitud aadress kuulub DHCP-serverile, mis tähendab, et tunnel on sillutatud või releeritud; ainult lüüsi poolist leitud aadress kuulub tunneli lõpp-punktile.

# 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

Kui vastus on selge, kirjutage üles neli asja: milline komponent määrab kliendi aadressi, milline vahemik on selle jaoks reserveeritud, kuidas tagasitulev liiklus sellesse vahemikku jõuab ja millised ressursid selle vastu võtavad. Need neli kirjet muudavad virtuaalseadapteri rea tööalaseks faktiks.

Korrake kontrolli DNS-atribuudi jaoks, kuni olete seal. Pool, mis jagab aadresse ilma nimeresolverita, jätab kliendi tema kohalikule DNS-ile, mis on teistsugune tõrge kui pool, mis jagab aadressi, mida LAN juba kasutab.