Un client VPN cu adresă LAN nu este în LAN

Clientul se conectează, primește 10.50.0.200 și nu poate ajunge la serverul de la 10.50.0.20 deși ambele numere sunt în același /24. Convingerea din spatele acelei configurații este că o adresă din prefixul LAN face clientul parte din LAN. Nu face. Clientul este pe un link punct la punct, serverul consideră destinația locală, iar partea lipsă este un răspuns de vecin pe care nimeni nu îl trimite.

Mitul: același prefix înseamnă același segment

Un prefix de adresă îi spune unei gazde ce destinații poate atinge direct și care au nevoie de un router. Nu îi spune gazdei cum este destinația conectată fizic și cu siguranță nu garantează că destinația poate răspunde la o cerere pe nivelul de legătură. Sunt întrebări diferite, la care răspund tabele diferite pe gazdă. Masca răspunde la prima și tabela de vecini la a doua, iar doar prima este sub controlul tău din partea VPN.

Când serverul trimite către 10.50.0.200, compară destinația cu propria mască, decide că adresa este on-link și întreabă segmentul local pentru adresa hardware care o deține. Cererea aceea iese pe interfața Ethernet, iar clientul VPN nu este acolo ca să o audă.

Nimic din configurația clientului nu poate repara asta din partea lui. Calea răspunsului depinde de un dispozitiv din LAN care răspunde în numele clientului, sau de faptul că clientul are o adresă pe care serverul nu o consideră locală.

Ce face de fapt gazda locală cu adresa

Comportamentul este ușor de observat și merită observat înainte de a schimba ceva. Uită-te la tabela de vecini pe o gazdă din LAN după ce a încercat să ajungă la client: o intrare incompletă sau eșuată este întregul diagnostic într-o linie. Acea linie îți spune și că defecțiunea este locală segmentului și nu undeva în interiorul tunelului.

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

Căutarea rutei va raporta destinația ca on-link prin interfața Ethernet, și exact aceasta este problema. Dacă intrarea de vecin rămâne incompletă cât timp sesiunea VPN este activă, ai confirmat că partea lipsă este rezolvarea pe nivelul de legătură, nu rutarea sau politica de firewall.

Rulează aceeași verificare de pe o gazdă dintr-o altă subrețea și compară. O gazdă care ajunge la client printr-un router nu are nevoie deloc de o intrare de vecin, iar diferența aceea este decizia de proiectare în miniatură.

Cum oferă proxy ARP următorul salt

proxy ARP face ca gateway-ul să răspundă la cererea de pe nivelul de legătură în numele unei destinații pe care o poate atinge prin altă interfață. Gazda din LAN primește o adresă hardware, trimite cadrul la gateway, iar gateway-ul trimite pachetul în sesiunea VPN. Din punctul de vedere al gazdei, clientul pare pur și simplu a fi în spatele gateway-ului. Nimic din configurația clientului nu se schimbă.

Documentația RouterOS despre ARP de la MikroTik descrie acea utilizare pentru clienții dial-in care împrumută spațiul de adrese al LAN-ului conectat. Mecanismul este o reparare a rezolvării vecinilor și funcționează pentru că gateway-ul este într-adevăr pe ambele căi.

Asta nu este același lucru cu a puntea clientul în LAN. Gateway-ul tot trebuie să trimită pachetul către sesiunea activă corectă, iar rutarea și politica sa de firewall tot trebuie să permită serviciul. proxy ARP schimbă cine răspunde la cererea de vecin, nu cine are voie să vorbească.

Citește cu atenție numele de mod ale platformei. RouterOS separă proxy-arp de local-proxy-arp, iar al doilea tratează traficul care intră și iese prin aceeași interfață. Nu sunt grafii interschimbabile, iar activarea ambelor fără discernământ nu este o scurtătură.

Ce nu îți dă proxy ARP

Nu oferă descoperire prin broadcast sau multicast. Un client care trebuie să găsească un serviciu prin broadcast va eșua în continuare, pentru că gateway-ul trimite unicast în sesiune și nu face clientul membru al domeniului de broadcast al LAN-ului. Protocoalele de descoperire care depind de broadcast sunt o sursă obișnuită de rapoarte că funcționează pentru un lucru și nu pentru altul în proiectele cu adrese împrumutate.

Nu rezervă adresa. Dacă numărul împrumutat se află și într-un pool DHCP sau într-o alocare statică, două dispozitive pot ajunge cu aceeași adresă, iar comportamentul rezultat depinde de moment. O autentificare reușită nu este o rezervare.

Și nu elimină nevoia de coordonare cu proprietarul LAN-ului. O intrare proxy ARP care surprinde proprietarul planului de adrese este un incident de suport care așteaptă o săptămână liniștită.

Comparație cu un pool rutat separat

Alternativa este să le dai clienților VPN propriul prefix și să lași gazdele din LAN să ruteze către el. Atunci serverul trimite răspunsuri off-link către gateway-ul său, gateway-ul rutează prefixul către punctul final al VPN, iar pe segmentul LAN nu este deloc nevoie de rezolvarea vecinilor. Sunt mai puține piese mobile decât o adresă împrumutată plus un răspuns proxy.

Acel proiect este mai ușor de gândit și mai ușor de auditat, pentru că intervalul clienților este vizibil separat de intervalul LAN. Costă o rută, o cale de întoarcere și o regulă de acces, adică exact lucrurile de care proiectul cu proxy ARP are nevoie într-un loc mai puțin evident.

Alege între modele în mod deliberat, nu din întâmplare. proxy ARP repară o relație anume; un pool rutat evită nevoia acelei reparații. Notează ce ai ales și de ce, iar următoarea persoană nu va trebui să redescopere asta dintr-o intrare de vecin eșuată.