’n VPN-kliënt met ’n LAN-adres is nie op die LAN nie

Die kliënt maak verbinding, kry 10.50.0.200 en kan nie die bediener by 10.50.0.20 bereik nie, al val albei nommers in dieselfde /24. Agter daardie opstelling sit die oortuiging dat ’n adres uit die LAN-prefiks die kliënt deel van die LAN maak. Dit doen dit nie. Die kliënt is op ’n punt-tot-punt-skakel, die bediener glo die bestemming is plaaslik, en die ontbrekende stuk is ’n buurantwoord wat niemand stuur nie.

Die mite: dieselfde prefiks beteken dieselfde segment

’n Adresprefiks vertel ’n gasheer watter bestemmings hy direk kan bereik en watter ’n router nodig het. Dit sê nie vir die gasheer hoe die bestemming fisies aangeheg is nie, en dit waarborg beslis nie dat die bestemming ’n skakellaagversoek kan beantwoord nie. Dit is verskillende vrae wat deur verskillende tabelle op die gasheer beantwoord word. Die masker beantwoord die eerste en die buurtabel die tweede, en net die eerste is van die VPN-kant af in jou beheer.

Wanneer die bediener na 10.50.0.200 stuur, vergelyk hy die bestemming met sy eie masker, besluit die adres is on-link en vra die plaaslike segment vir die hardeware-adres wat dit besit. Daardie versoek gaan oor die Ethernet-koppelvlak uit, en die VPN-kliënt is nie daar om dit te hoor nie.

Niks in die kliënt se opstelling kan dit van sy kant af regstel nie. Die antwoordpad hang daarvan af dat ’n toestel op die LAN namens die kliënt antwoord, of dat die kliënt ’n adres het wat die bediener nie as plaaslik beskou nie.

Wat die plaaslike gasheer werklik met die adres doen

Die gedrag is maklik om waar te neem en die moeite werd om te sien voordat jy iets verander. Kyk op ’n LAN-gasheer na die buurtabel nadat dit die kliënt probeer bereik het: ’n onvolledige of mislukte inskrywing is die hele diagnose in een reël. Daardie reël sê ook vir jou die fout is plaaslik in die segment en nie ergens in die tonnel nie.

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

Die roetesoektog sal die bestemming as on-link rapporteer deur die Ethernet-koppelvlak, en dit is presies die probleem. As die buurinskrywing onvolledig bly terwyl die VPN-sessie op is, het jy bevestig dat die ontbrekende stuk skakellaagresolusie is en nie roetering of firewall-beleid nie.

Voer dieselfde kontrole uit vanaf ’n gasheer in ’n ander subnet en vergelyk. ’n Gasheer wat die kliënt deur ’n router bereik, het glad nie ’n buurinskrywing nodig nie, en daardie verskil is die ontwerpbesluit in die klein.

Hoe proxy ARP ’n volgende sprong verskaf

Proxy ARP laat die gateway die skakellaagversoek beantwoord namens ’n bestemming wat hy deur ’n ander koppelvlak kan bereik. Die LAN-gasheer ontvang ’n hardeware-adres, stuur die raam na die gateway, en die gateway stuur die pakket in die VPN-sessie in. Vanuit die gasheer se oogpunt lyk dit eenvoudig of die kliënt agter die gateway is. Niks aan die kliënt se opstelling verander nie.

MikroTik se RouterOS ARP-dokumentasie beskryf dié gebruik vir inbelkliënte wat die gekoppelde LAN se adresruimte leen. Die meganisme is ’n regstelling van buurresolusie, en dit werk omdat die gateway werklik op albei paaie is.

Dit is nie dieselfde as om die kliënt in die LAN in te brug nie. Die gateway moet die pakket steeds na die regte aktiewe sessie stuur, en sy roetering- en firewall-beleid moet die diens steeds toelaat. Proxy ARP verander wie die buurversoek beantwoord, nie wie mag praat nie.

Lees die platform se modusname noukeurig. RouterOS skei proxy-arp van local-proxy-arp, en die tweede hanteer verkeer wat dieselfde koppelvlak binnekom en verlaat. Dit is nie uitruilbare spellings nie, en om albei onoordeelkundig te aktiveer is nie ’n kortpad nie.

Wat proxy ARP jou nie gee nie

Dit verskaf geen uitsaai- of multisaai-ontdekking nie. ’n Kliënt wat ’n diens per uitsaai moet vind, sal steeds misluk, want die gateway stuur unicast na die sessie en maak die kliënt nie ’n lid van die LAN se uitsaai-domein nie. Ontdekkingsprotokolle wat op uitsaai staatmaak, is by leningsadres-ontwerpe ’n algemene bron van berigte dat dit vir die een ding werk en vir die ander nie.

Dit reserveer nie die adres nie. As die geleende nommer ook in ’n DHCP-poel of ’n statiese toewysing sit, kan twee toestelle dieselfde adres kry, en die gevolglike gedrag hang van tydsberekening af. ’n Suksesvolle aanmelding is nie ’n reservering nie.

En dit verwyder nie die noodsaak om met die eienaar van die LAN te koördineer nie. ’n Proxy ARP-inskrywing wat die eienaar van die adresplan verras, is ’n ondersteuningsgeval wat op ’n stil week wag.

Vergelyk met ’n apart gerouteerde poel

Die alternatief is om VPN-kliënte hul eie prefiks te gee en LAN-gashere daarheen te laat roeteer. Die bediener stuur dan van-skakel-antwoorde na sy gateway, die gateway roeteer die prefiks na die VPN-eindpunt, en op die LAN-segment is glad geen buurresolusie nodig nie. Dit is minder bewegende dele as ’n geleende adres plus ’n proxy-antwoord.

Daardie ontwerp is makliker om te beredeneer en makliker om te oudit, want die kliëntreeks is sigbaar apart van die LAN-reeks. Dit kos ’n roete, ’n terugpad en ’n toegangsreël, dieselfde dinge wat die proxy ARP-ontwerp op ’n minder ooglopende plek nodig het.

Kies doelbewus tussen die modelle en nie per ongeluk nie. Proxy ARP herstel een spesifieke verhouding; ’n gerouteerde poel maak daardie herstelling onnodig. Skryf neer watter een jy gekies het en waarom, dan hoef die volgende persoon dit nie uit ’n mislukte buurinskrywing te herontdek nie.