LAN-aadressiga VPN-klient ei ole LAN-is

Klient ühendub, saab 10.50.0.200 ja ei pääse serverini aadressil 10.50.0.20, kuigi mõlemad numbrid on samas /24-s. Selle konfiguratsiooni taga on uskumus, et LAN-i prefiksist pärit aadress teeb kliendi LAN-i osaks. Ei tee. Klient on punkt-punkti lingil, server peab sihtkohta kohalikuks ja puuduv tükk on naabri vastus, mida keegi ei saada.

Müüt: sama prefiks tähendab sama segmenti

Aadressi prefiks ütleb hostile, milliseid sihtkohti saab ta otse kätte ja millised vajavad ruuterit. See ei ütle hostile, kuidas sihtkoht on füüsiliselt ühendatud, ja kindlasti ei taga, et sihtkoht suudab vastata linkkihi päringule. Need on erinevad küsimused, millele vastavad hosti erinevad tabelid. Mask vastab esimesele ja naabritabel teisele, ning ainult esimene on VPN-i poolelt teie kontrolli all.

Kui server saadab aadressile 10.50.0.200, võrdleb ta sihtkohta oma maskiga, otsustab, et aadress on on-link, ja küsib kohalikult segmendilt sellele kuuluvat riistvaraaadressi. See päring väljub Ethernet-liidese kaudu ja VPN-klient ei ole seal seda kuulamas.

Miski kliendi konfiguratsioonis ei saa seda tema poolt parandada. Vastuse tee sõltub sellest, kas LAN-is olev seade vastab kliendi eest, või sellest, et kliendil on aadress, mida server ei pea kohalikuks.

Mida kohalik host aadressiga tegelikult teeb

Käitumist on lihtne jälgida ja seda tasub jälgida enne, kui midagi muudate. Vaadake LAN-hostis naabritabelit pärast seda, kui see on proovinud kliendini jõuda: puudulik või ebaõnnestunud kirje on kogu diagnoos ühes reas. See rida ütleb teile ka, et viga on segmendi kohalik, mitte kuskil tunnelis.

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

Marsruudiotsing teatab sihtkoha on-linkina läbi Ethernet-liidese ja täpselt see on probleem. Kui naabrikirje jääb puudulikuks, kuni VPN-seanss on üleval, olete kinnitanud, et puuduv tükk on linkkihi lahendus, mitte marsruutimine või tulemüüri poliitika.

Tehke sama kontroll teise alamvõrgu hostist ja võrrelge. Host, mis jõuab kliendini ruuteri kaudu, ei vaja naabrikirjet üldse, ja see erinevus on disainiotus miniatuuris.

Kuidas proxy ARP järgmise hüppe annab

Proxy ARP paneb lüüsi vastama linkkihi päringule sihtkoha eest, milleni ta pääseb teise liidese kaudu. LAN-host saab riistvaraaadressi, saadab kaadri lüüsile ja lüüs edastab paketi VPN-seanssi. Hosti vaatenurgast näeb klient lihtsalt välja nagu oleks lüüsi taga. Kliendi konfiguratsioonis ei muutu miski.

MikroTiku RouterOS-i ARP dokumentatsioon kirjeldab seda kasutust sissehelistavate klientide jaoks, kes laenavad ühendatud LAN-i aadressiruumi. Mehhanism on naabrilahenduse parandus ja see töötab, sest lüüs on tõesti mõlemal teel.

See ei ole sama, mis kliendi sillutamine LAN-i. Lüüs peab ikkagi paketi edastama õigesse aktiivsesse seanssi ning tema marsruutimine ja tulemüüri poliitika peavad teenust ikkagi lubama. Proxy ARP muudab, kes naabripäringule vastab, mitte kes tohib rääkida.

Lugege platvormi režiiminimesid hoolikalt. RouterOS eristab proxy-arp ja local-proxy-arp ning teine käsitleb liiklust, mis siseneb ja väljub samast liidesest. Need ei ole vahetatavad kirjaviisid ja mõlema valimatu lubamine ei ole lühike tee.

Mida proxy ARP teile ei anna

See ei anna broadcast- ega multicast-avastust. Klient, kes peab teenuse leidma broadcasti abil, ebaõnnestub ikkagi, sest lüüs edastab unicasti seanssi ega tee klienti LAN-i broadcast-domeeni liikmeks. Broadcastile toetuvad avastusprotokollid on laenatud aadressidega disainides tavaline allikas teadetest, et ühe asja jaoks töötab ja teise jaoks mitte.

See ei broneeri aadressi. Kui laenatud number on ka DHCP-kogumis või staatilises määrangus, võivad kaks seadet jõuda sama aadressini ja tulemuslik käitumine sõltub ajastusest. Edukas sisselogimine ei ole broneering.

Ja see ei kõrvalda vajadust kooskõlastada LAN-i omanikuga. Proxy ARP kirje, mis aadressiplaani omanikku üllatab, on tugijuhtum, mis ootab vaikset nädalat.

Võrdlus eraldi marsruuditud kogumiga

Alternatiiv on anda VPN-klientidele oma prefiks ja lasta LAN-hostidel sinna marsruutida. Siis saadab server off-link vastused oma lüüsile, lüüs marsruudib prefiksi VPN-i lõpp-punkti ja LAN-segmendis ei ole naabrilahendust üldse vaja. See on vähem liikuvaid osi kui laenatud aadress pluss proxy-vastus.

Seda disaini on lihtsam läbi mõelda ja auditeerida, sest kliendivahemik on nähtavalt LAN-i vahemikust eraldi. See maksab marsruudi, tagasitee ja juurdepääsureegli, samad asjad, mida proxy ARP disain vajab vähem ilmekas kohas.

Valige mudelite vahel teadlikult, mitte kogemata. Proxy ARP parandab ühe konkreetse suhte; marsruuditud kogum kaotab selle paranduse vajaduse. Kirjutage üles, millise valisite ja miks, ja järgmine inimene ei pea seda ebaõnnestunud naabrikirjest uuesti avastama.