Kāpēc LAN resursdators sūta ARP uz OpenVPN klienta adresi

Sasniedzamības problēmas starp LAN resursdatoru un VPN klientu bieži vien ved atpakaļ pie paša adrešu plāna. Piešķiriet šim resursdatoram saskarni 10.0.100.0/22 un tas katru adresi no 10.0.100.0 līdz 10.0.103.255 uzskatīs par tieši pieslēgtu, tostarp klientu kopu, kas klusi atrodas 10.0.101.0/24. Atbilde nekad neiet uz maršrutētāju, jo no resursdatora viedokļa neviens maršrutētājs nepiedalās. Pakete ir adresēta kaimiņam un tiek pieprasīta uz vada.

Šis mehānisms slēpjas aiz veselas ziņojumu saimes: tunelis ir aktīvs, serverim ir maršruts, un LAN resursdators joprojām nevar sasniegt klientu.

/22 prefikss, kas aprij /24

Lasiet prefiksu kā diapazonu, nevis kā virkni. /22 prefiksā ir 1024 adreses, un 10.0.100.0/22 stiepjas no 10.0.100.0 līdz 10.0.103.255, tāpēc kopa 10.0.101.0/24 atrodas pilnībā tā iekšienē. Kļūda pārdzīvo pārskatīšanu, jo kopas pirmie okteti izskatās citādi nekā LAN pirmie okteti, un tikai trešais oktets atklāj iekļaušanos. Pierakstiet abus diapazonus skaitļos, pirms pasludināt tos atsevišķus.

Tā pati iekļaušanās var parādīties arī pretēji. Kopa, kas šķiet brīva, jo neviens to tagad neizmanto, tomēr var iekļūt prefiksā, ko reklamē kāds vietnes maršrutētājs, un adrešu plāns ir vienīgais dokuments, kas to parāda.

Tiešs savienojums nozīmē ARP, nevis maršrutēšanu

Kad resursdators ar /22 saskarni sūta uz 10.0.101.25, kodols salīdzina galamērķi ar saskarnes prefiksu un atrod atbilstību. Pakete kļūst par kaimiņa meklēšanu, nevis maršrutētu paketi, un Ethernet tīklā kaimiņa meklēšana ir ARP pieprasījums šai adresei. Ja adrese pieder VPN klientam aiz maršrutētiem vārtiem, neviens LAN resursdators to nepiešķir, tāpēc pieprasījums paliek bez atbildes un paketes tiek izmestas. Tunelis nav vainīgs, un klients nekad neredz satiksmi.

Tāpēc kļūme izskatās asimetriska un dažkārt pārtraukta. VPN resursdators bieži sasniedz LAN, jo tā paša maršruti norāda pareizajā virzienā, kamēr LAN resursdators nevar atbildēt, un jebkas, kas kešatmiņā glabā novecojušu ARP ierakstu, liek simptomam mirgot.

TUN, TAP un ko katrs pārnēsā

TUN ierīce pārnēsā IP paketes, un TAP ierīce pārnēsā Ethernet kadrus. Maršrutēts TUN savienojums nav jāpārnēsā ARP, lai nodrošinātu IP sasniedzamību, un tieši tāpēc iepriekš minētais neatbildētais pieprasījums ir gaidāms, nevis salauzts. TAP ar apzināti izveidotu tiltu var paplašināt apraides domēnu un likt ARP darboties, bet tas maina to, ko klients var redzēt, prasa galapunktus, kas atbalsta to pašu iekadrēšanu, un ir tīkla modeļa pārprojektēšana, nevis pārklājošā prefiksa labošana. Maršrutētas ieviešanas pārslēgšana uz TAP, lai izārstētu adrešu plāna kļūdu, mazu problēmu apmaina pret lielāku.

Pierakstiet, kur parādījās ARP pieprasījums un kura sistēma to nosūtīja, pirms izdarīt secinājumus. Sūtītājs jums stāsta, ko tas domā par galamērķi, nevis ko dara tunelis.

Projektējiet kopu, kas nevar pārklāties

Izvēlieties kopu ārpus katra pieslēgtā prefiksa un katra reklamētā vietnes prefiksa, pēc tam pievienojiet maršrutus, kas padara to sasniedzamu abos virzienos. Diapazons, piemēram, 10.8.0.0/24 neizmantotā plāna daļā, ir viegli pārdomājams, un LAN, kuram tas jāsasniedz, iegūst statisku maršrutu, kas norāda uz VPN serveri. Mainiet kopā piešķīrumu, reklamētos maršrutus, atļautās avota adreses un ugunsmūra noteikumus, jo tie apraksta vienu projektu, nevis četrus iestatījumus.

Source NAT serverī var paslēpt kopu aiz adreses, kas maršrutējama no LAN, un tas ir likumīgs migrācijas instruments. Tas arī pārraksta avotu, tāpēc LAN zaudē iespēju attiecināt savienojumus uz atsevišķiem klientiem un piemērot noteikumus katram klientam.

Pieņemšanai izmantojiet reālā klienta faktiski piešķirto adresi un reālu lietojumprogrammas pieprasījumu no LAN resursdatora, pēc tam apstipriniet, ka atbilde seko plānotajiem vārtiem, nevis vadam.