In VPN-klant mei in LAN-adres is net op ’e LAN

De klant ferbynt, krijt 10.50.0.200 en kin de server op 10.50.0.20 net berikke, ek al lizze beide nûmers yn deselde /24. It leauwen efter dy konfiguraasje is dat in adres út it LAN-prefiks de klant diel fan ’e LAN makket. Dat docht it net. De klant sit op in punt-nei-punt-link, de server tinkt dat de bestimming lokaal is, en it ûntbrekkende stik is in buorman-antwurd dat nimmen stjoert.

De myte: itselde prefiks betsjut itselde segmint

In adresprefiks fertelt in host hokker bestimmingen er direkt berikke kin en hokker in router nedich hawwe. It fertelt de host net hoe’t de bestimming fysyk ferbûn is, en it garandearret seker net dat de bestimming antwurdzje kin op in fersyk op ’e linklaach. Dat binne ferskillende fragen, beantwurde troch ferskillende tabellen op ’e host. It masker beantwurdet de earste en de buormantabel de twadde, en allinnich de earste is fan ’e VPN-kant ôf ûnder jo kontrôle.

As de server nei 10.50.0.200 stjoert, ferget it de bestimming mei syn eigen masker, beslút dat it adres on-link is, en freget it lokale segmint om it hardware-adres dat derby heart. Dat fersyk giet oer de Ethernet-ynterface nei bûten, en de VPN-klant is dêr net om it te hearren.

Neat yn ’e konfiguraasje fan ’e klant kin dat fan syn kant ôf reparearje. It antwurdpaad hinget ôf fan in apparaat op ’e LAN dat út namme fan ’e klant antwurdet, of fan it feit dat de klant in adres hat dat de server net as lokaal beskôget.

Wat de lokale host eins mei it adres docht

It gedrach is maklik te observearjen en wurdich om te observearjen foardat jo eat feroarje. Sjoch op in LAN-host nei de buormantabel neidat er besocht hat de klant te berikken: in ûnfolsleine of mislearre yngong is de hiele diagnoaze yn ien rigel. Dy rigel fertelt jo ek dat de fout lokaal foar it segmint is en net earne yn ’e tunnel.

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

De rûtesyk rapportearret de bestimming as on-link fia de Ethernet-ynterface, en dat is krekt it probleem. As de buormyngong ûnfolslein bliuwt wylst de VPN-sesje oan is, hawwe jo befêstige dat it ûntbrekkende stik resolúsje op ’e linklaach is en net routing of firewallbelied.

Doch deselde kontrôle fan in host yn in oar subnetsje en fergelykje. In host dy’t de klant fia in router berikt, hat hielendal gjin buormyngong nedich, en dat ferskil is de ûntwerpbeslissing yn it lyts.

Hoe proxy ARP in folgjende hop leveret

Proxy ARP makket dat de gateway it fersyk op ’e linklaach beantwurdet út namme fan in bestimming dy’t er fia in oare ynterface berikke kin. De LAN-host krijt in hardware-adres, stjoert it frame nei de gateway, en de gateway stjoert it pakket troch nei de VPN-sesje. Fan ’e host út sjoen liket de klant gewoan efter de gateway te sitten. Neat oan ’e konfiguraasje fan ’e klant feroaret.

De RouterOS ARP-dokumintaasje fan MikroTik beskriuwt dat gebrûk foar dial-in-klanten dy’t de adresromte fan ’e oansletten LAN liene. It meganisme is in reparaasje fan ’e buormanresolúsje, en it wurket omdat de gateway echt op beide paden sit.

Dat is net itselde as de klant yn ’e LAN brêgje. De gateway moat it pakket noch altyd trochstjoere nei de juste aktive sesje, en syn routing en firewallbelied moatte de tsjinst noch altyd tastean. Proxy ARP feroaret wa’t it buormanfersyk beantwurdet, net wa’t prate mei.

Lês de modusnammen fan it platfoarm soarchfâldich. RouterOS skiedt proxy-arp fan local-proxy-arp, en de twadde behannelet ferkear dat troch deselde ynterface yn en út giet. Dat binne gjin útwikselbere staveringswizen, en beide sûnder ûnderskie ynskeakelje is gjin koarte wei.

Wat proxy ARP jo net jout

It leveret gjin broadcast- of multicast-ûntdekking. In klant dy’t in tsjinst fia broadcast fine moat, sil noch altyd mislearje, om’t de gateway unicast nei de sesje stjoert en de klant gjin lid fan it broadcast-domein fan ’e LAN makket. Untdekkingsprotokollen dy’t op broadcast fertrouwe binne in gewoane boarne fan berjochten dat it foar it iene wurket en foar it oare net, yn ûntwerpen mei liende adressen.

It reservearret it adres net. As it liende nûmer ek yn in DHCP-pool of in statyske tawizing sit, kinne twa apparaten mei itselde adres einigje en it resultearjende gedrach hinget ôf fan timing. In slagge oanmelding is gjin reservaasje.

En it hellet de needsaak net fuort om te koördinearjen mei wa’t de LAN besit. In proxy ARP-yngong dy’t de eigner fan it adresplan ferrast, is in stipe-ynsidint dat op in rêstich wykein wachtet.

Fergelykje mei in apart routed pool

It alternatyf is om VPN-klanten har eigen prefiks te jaan en LAN-hosts dêrhinne route te litten. Dan stjoert de server off-link-antwurden nei syn gateway, de gateway rûtet it prefiks nei it VPN-einpunt, en op it LAN-segmint is hielendal gjin buormanresolúsje nedich. Dat binne minder beweegbere dielen as in liend adres plus in proxy-antwurd.

Dat ûntwerp is makliker te beredenearen en makliker te auditearjen, om’t it klantberik sichtber apart is fan it LAN-berik. It kostet in rûte, in weromwei en in tagongsregel, deselde dingen dy’t it proxy ARP-ûntwerp op in minder foar de hân lizzend plak nedich hat.

Kies bewust tusken de modellen en net by tafal. Proxy ARP reparearret ien spesifike relaasje; in routed pool foarkomt dat dy reparaasje nedich is. Skriuw op hokker jo keazen hawwe en wêrom, dan hoecht de folgjende persoan it net op ’e nij te ûntdekken út in mislearre buormyngong.