VPN adrese pret LAN DHCP nomu: kas piešķir tuneļa IP?

Pievienojiet klientu un skatieties adapteri, nevis Wi-Fi ikonu. Tāda adrese kā 10.80.0.14 var atrasties tunelī, lai gan neviens DHCP serveris biroja LAN tīklā nekad nav reģistrējis šo nomu. Tieši process, kas izvēlējās numuru, nosaka, kur sākt problēmu meklēšanu.

Klientā viss izskatās vienādi: viena IPv4 adrese, viena maska, dažreiz noklusējuma vārteja. Atšķirība parādās tikai tad, kad jautājat, kas atbild par šo adresi un kas par to veic uzskaiti.

Nolasiet tuneļa adresi no klienta puses

Windows parāda atšķirību, ja lasāt visu bloku, nevis pirmo rindu. ipconfig /all izdrukā adaptera aprakstu, fizisko adresi un DHCP rindu. PPP vai IKEv2 zvanīšanas adapters parasti ziņo DHCP kā atspējotu, jo savienojums adresi saskaņoja zvanīšanas laikā, nevis nomāja to no LAN servera. Tuneļa adapters ar iespējotu DHCP ir neparasts un pelna atsevišķu izpēti.

Linux sadala to pašu informāciju diviem rīkiem. ip -4 addr show dev tun0 dod adresi un prefiksa garumu. nmcli -f IP4 connection show work atklāj, vai vērtība nāca no savienojuma profila, DHCP apmaiņas uz saites vai iespiestas konfigurācijas. WireGuard ir visskaidrākais gadījums, jo wg-quick piemēro konfigurācijas faila rindu Address, kad saskarne parādās, un neviens partneris pieslēgšanās laikā neko nepiešķir.

Prefikss arī kaut ko pasaka. /32 vai maska 255.255.255.255 nozīmē, ka vārteja sagaida maršrutēšanu uz vienu resursdatora adresi, bet plašāka maska norāda uz saites apakštīklu kaut kur aiz tuneļa.

Ko nes IKEv2 konfigurācijas krava

IKEv2 ir īpašs mehānisms šim darbam. RFC 7296, sadaļā 3.15.1 aprakstītā konfigurācijas krava nes atribūtus, piemēram, INTERNAL_IP4_ADDRESS, INTERNAL_IP4_NETMASK, INTERNAL_IP4_DNS un to IPv6 ekvivalentus. Klients sūta atribūtu ar nulles garuma vērtību, ja tam nav izvēles, un atbildētājs atgriež vērtību, ko vēlas izmantot. Šī apmaiņa notiek IKE_AUTH iekšienē, jau šifrēta, tāpēc neviena DHCP apraide nekad nešķērso tuneli.

No tā izriet divas sekas. Pirmkārt, adresi izvēlas atbildētājs vai jebkura autorizācijas aizmugursistēma, ar ko tas konsultējas, tāpēc kopa var atrasties uz vārtejas, RADIUS atbildē vai identitātes nodrošinātāja kartējumā. Otrkārt, DNS atribūts ir atsevišķi no adreses atribūta. 10.80.0.14 saņemšana neko nepasaka par to, kurš atrisinātājs atgriezās vai vai kāds vispār atgriezās.

Tīkla maskas atribūts praksē ir neobligāts. Daudzi izvietojumi atgriež tikai adresi un ļauj klientam instalēt resursdatora maršrutu, tāpēc viena un tā pati kopa vienā klientā var izskatīties kā /32, bet citā kā /24.

Kur saduras LAN DHCP apgabals un VPN kopa

Problēmas sākas, kad abi piešķīrēji norāda uz vienu diapazonu. 10.20.30.0/24 DHCP serveris neko nezina par VPN kopu, kas konfigurēta 10.20.30.128/25, tāpēc nekas neliedz tam iznomāt 10.20.30.140 printerim, kamēr vārteja to pašu adresi dod attālinātam klientam. Sadursme paliek klusa vairākas dienas un pēc tam parādās kā periodisks dublikāts.

Maršrutēts vietnes-uz-vietni dizains izvairās no sadursmes pēc uzbūves. Filiāles resursdators patur adresi, ko tam deva vietējais DHCP serveris. Abu vārteju tuneļa saskarnes nes savas saites adreses, un maršrutēšanas tabula izlemj, kā ceļo paketes. Attālinātās piekļuves klientu adreses ir trešā kategorija, un tās nevajadzētu jaukt ar vārtejas saites adresēm.

Tuneļa savienošana ar LAN tiltu noņem šo atdalījumu. Ja dizainam patiešām vajag vienu apraides domēnu, VPN galapunktam jāpiedalās tajos pašos piešķiršanas lēmumos kā DHCP serverim, izmantojot releju vai kopīgu autoritatīvu avotu, nevis pašam izdot adreses.

Pārbaudiet, kuram procesam pieder adrese

Pierādiet īpašumtiesības pirms apgabala maiņas. Klientā pierakstiet adresi un prefiksu. LAN tīklā meklējiet nomes datubāzē. Vārtējā uzskaitiet kopas, ko tā ir konfigurēta izsniegt. Nomes failā atrastā adrese pieder DHCP serverim, kas nozīmē, ka tunelis ir savienots ar tiltu vai pārraidīts ar releju; adrese, kas atrasta tikai vārtejas kopā, pieder tuneļa galapunktam.

# 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

Kad atbilde ir skaidra, pierakstiet četras lietas: kura komponente piešķir klienta adresi, kāds diapazons tam ir rezervēts, kā atgriešanās trafiks sasniedz šo diapazonu un kuri resursi to pieņem. Šie četri ieraksti pārvērš virtuālā adaptera rindu darbības faktā.

Atkārtojiet pārbaudi DNS atribūtam, kamēr esat tur. Kopa, kas izsniedz adreses bez atrisinātāja, atstāj klientu uz tā vietējo DNS, kas ir cita veida kļūme nekā kopa, kas izsniedz adresi, ko LAN jau izmanto.