VPN klients ar LAN adresi nav LAN tīklā

Klients pieslēdzas, saņem 10.50.0.200 un nevar sasniegt serveri 10.50.0.20, lai gan abi numuri ir vienā /24. Šīs konfigurācijas pamatā ir pārliecība, ka adrese no LAN prefiksa padara klientu par LAN daļu. Tas tā nav. Klients atrodas punkta-punkta saitē, serveris uzskata galamērķi par vietēju, un trūkstošā daļa ir kaimiņa atbilde, ko neviens nesūta.

Mīts: viens un tas pats prefikss nozīmē to pašu segmentu

Adreses prefikss pasaka resursdatoram, kurus galamērķus tas sasniedz tieši un kuriem vajag maršrutētāju. Tas nepaskaidro, kā galamērķis ir fiziski pievienots, un galīgi negarantē, ka galamērķis varēs atbildēt uz saites slāņa pieprasījumu. Tie ir dažādi jautājumi, uz kuriem atbild dažādas resursdatora tabulas. Maska atbild uz pirmo, kaimiņu tabula uz otro, un tikai pirmais ir tavā kontrolē no VPN puses.

Kad serveris sūta uz 10.50.0.200, tas salīdzina galamērķi ar savu masku, nolemj, ka adrese ir on-link, un jautā vietējam segmentam aparatūras adresi, kas tai pieder. Šis pieprasījums iziet caur Ethernet saskarni, un VPN klients nav tur, lai to dzirdētu.

Nekas klienta konfigurācijā nevar to izlabot no viņa puses. Atbildes ceļš ir atkarīgs no tā, vai ierīce LAN tīklā atbildēs klienta vārdā, vai arī klientam būs adrese, ko serveris neuzskata par vietēju.

Ko vietējais resursdators patiešām dara ar adresi

Uzvedību ir viegli novērot, un to ir vērts novērot pirms kaut ko mainīt. Paskatieties uz LAN resursdatora kaimiņu tabulu pēc tam, kad tas mēģināja sasniegt klientu: nepilnīgs vai neizdevies ieraksts ir visa diagnoze vienā rindā. Šī rinda arī pasaka, ka kļūme ir lokāla segmentam, nevis kaut kur tunelī.

ip neigh show 10.50.0.200
ip route get 10.50.0.200
arping -I eth0 -c 3 10.50.0.200

Maršruta meklēšana ziņos galamērķi kā on-link caur Ethernet saskarni, un tieši tā ir problēma. Ja kaimiņa ieraksts paliek nepilnīgs, kamēr VPN sesija darbojas, jūs esat apstiprinājis, ka trūkstošā daļa ir saites slāņa risinājums, nevis maršrutēšana vai ugunsmūra politika.

Veiciet to pašu pārbaudi no resursdatora citā apakštīklā un salīdziniet. Resursdatoram, kas sasniedz klientu caur maršrutētāju, kaimiņa ieraksts vispār nav vajadzīgs, un šī atšķirība ir dizaina lēmums mazā mērogā.

Kā proxy ARP nodrošina nākamo lēcienu

proxy ARP liek vārtejai atbildēt uz saites slāņa pieprasījumu tā galamērķa vārdā, kuru tā var sasniegt caur citu saskarni. LAN resursdators saņem aparatūras adresi, nosūta kadru vārtejai, un vārteja pārsūta paketi VPN sesijā. No resursdatora viedokļa klients vienkārši izskatās kā aiz vārtejas. Klienta konfigurācijā nekas nemainās.

MikroTik RouterOS ARP dokumentācija apraksta šo lietojumu dial-in klientiem, kas aizņemas pievienotā LAN adrešu telpu. Mehānisms ir kaimiņu risinājuma labojums, un tas darbojas tāpēc, ka vārteja patiešām atrodas abos ceļos.

Tas nav tas pats, kas klienta tiltēšana LAN tīklā. Vārtejai joprojām ir jāpārsūta pakete uz pareizo aktīvo sesiju, un tās maršrutēšanai un ugunsmūra politikai joprojām ir jāatļauj pakalpojums. proxy ARP maina to, kas atbild uz kaimiņa pieprasījumu, nevis to, kam ir atļauts runāt.

Uzmanīgi lasiet platformas režīmu nosaukumus. RouterOS atšķir proxy-arp no local-proxy-arp, un otrais apstrādā trafiku, kas ieiet un iziet caur to pašu saskarni. Tie nav aizvietojami rakstības varianti, un abu ieslēgšana bez izvēles nav īsceļš.

Ko proxy ARP jums nedod

Tas nenodrošina broadcast vai multicast atklāšanu. Klients, kam pakalpojums jāatrod ar broadcast, joprojām cietīs neveiksmi, jo vārteja pārsūta unicast uz sesiju un nepadara klientu par LAN broadcast domēna dalībnieku. Broadcast atkarīgie atklāšanas protokoli ir biežs avots ziņojumiem, ka vienai lietai tas strādā, bet citai ne, projektos ar aizņemtiem adresēm.

Tas nerezervē adresi. Ja aizņemtais numurs ir arī DHCP baseinā vai statiskā piešķīrumā, divas ierīces var nonākt pie vienas adreses, un rezultāts ir atkarīgs no laika. Veiksmīga pieteikšanās nav rezervācija.

Un tas nenovērš vajadzību saskaņot ar LAN īpašnieku. proxy ARP ieraksts, kas pārsteidz adrešu plāna īpašnieku, ir atbalsta incidents, kas gaida mierīgu nedēļu.

Salīdzinājums ar atsevišķi maršrutētu baseinu

Alternatīva ir dot VPN klientiem savu prefiksu un ļaut LAN resursdatoriem maršrutēt uz to. Tad serveris sūta off-link atbildes savai vārtejai, vārteja maršrutē prefiksu uz VPN galapunktu, un LAN segmentā kaimiņu risinājums vispār nav vajadzīgs. Tas ir mazāk kustīgu daļu nekā aizņemta adrese plus proxy atbilde.

Šo dizainu ir vieglāk pārdomāt un vieglāk auditēt, jo klientu diapazons ir redzami atdalīts no LAN diapazona. Tas maksā maršrutu, atgriešanās ceļu un piekļuves noteikumu, tās pašas lietas, kas proxy ARP dizainam vajadzīgas mazāk acīmredzamā vietā.

Izvēlieties starp modeļiem apzināti, nevis nejauši. proxy ARP salabo vienu konkrētu attiecību; maršrutēts baseins novērš vajadzību pēc šī labojuma. Pierakstiet, ko izvēlējāties un kāpēc, un nākamajam cilvēkam tas nebūs no jauna jāatklāj no neizdevušā kaimiņa ieraksta.