Zure VPN pool-a ez da LANeko DHCP barrutia: zergatik hausten den

Bide labur erakargarria da VPN bezeroei bulegoko DHCP zerbitzariak erabiltzen duen barruti beretik helbideak ematea, dena sare bakarra delakoan. Ez da. Bideratutako tunel batek unicast paketeak eramaten ditu bi muturren artean, eta LANeko poolak segmentu fisiko batean broadcast eskaerei erantzuteko existitzen dira. Zenbakiak berrerabiltzeak bi banatzaile jartzen ditu helbide-espazio baten kargu, eta itzulera-bidea zehaztu gabe uzten du.

Bi banatzaile, helbide-espazio bat

LANeko DHCP zerbitzariak badaki zein helbide alokatu dituen eta zein MAC helbideri, eta ARPrekin defendatzen ditu. VPN zerbitzariak bere pool propioa du eta ez daki ezer alokairu horiei buruz. Inor ez dago oker; inoiz ez zituzten aurkeztu elkarri.

VPN zerbitzariak ematen duen LANeko pooleko helbide bat inprimagailu batena izan daiteke jada. Orain bi gailuk helbide bat eskatzen dute aurrizki berean, eta switcharen aurreratze-taulak erabakitzen du zeinek erantzungo duen.

Hori da jendeak lehenengo aurkitzen duen hutsegitea: ondo konektatzen duen bezero bat eta gero makina okerrean amaitzen duena, edo zuzena tarteka iristen dena.

Zergatik ez ditu routerrak VPN helbideak banatzen

DHCP aurkikuntza broadcast bat da, eta broadcastak muga bideratu batean gelditzen dira. Diseinuak tunela zubiratzen ez badu edo dagokion agintea duen DHCP errele bat exekutatzen ez badu, bezeroaren eskaerak ez du inoiz LANeko zerbitzaria lortzen.

Beraz, VPN zerbitzariak berak esleitzen du helbidea: zerbitzariaren konfigurazioko pool bat, peer bakoitzeko helbide bat WireGuard konfigurazio batean, edo IKEv2 ezarpen batean autentifikazio-geruzak bultzatutako helbide bat. Mekanismo horiek independenteak dira LANeko alokairu-datu-basetik, eta horregatik bertatik behar dute beren barruti propioa.

Arrazoibide berak azaltzen du zergatik DHCP esparrua aldatzeak ez duen konpontzen inoiz helbiderik lortzen ez duen VPN bezero bat. Bezeroa ez dio LANeko zerbitzariari galdetzen, eta esparrua editatzeko edozein ahaleginak ez du galdetzera behartuko.

Gainjartzea gatazka gisa agertzen da, ez sare motel gisa

Laguntza duen diseinurik gabe aurrizki bat partekatzen duten bi sare jabetza bikoitzaren arazo ezberdin bat dira, eta askotan nahasten dira. VPN poolak aurrizki bereizi bat badu, gainjartzeak garrantzia du soilik bide batek trafikoa alde okerrean bidaltzen duenean. Poola LANeko aurrizkiaren barruan badago, gatazka berehalakoa eta lokala da.

Praktikan gailu okerreko ARP erantzunak ikusten dituzu, erdian berrezartzen diren konexioak, eta norbait beste batek bere helbidea eskatzen dion bezero bat. Horietako ezerk ez dirudi bideratze arazo bat, eta horregatik aplikatzen da konponketa geruza okerrean. Alokairu bikoitza erraza da baieztatzen eta gogaikarria da harekin bizitzea. Berrabiarazteak gainditzen ditu ere, bi banatzaileek helbide bera eskatu eta eskatu jarraitzen dutelako.

Itzulera-bidea arazo aparta da

Pool garbi eta bereizi batekin ere, LANeko ostalariak jakin behar du nola erantzun bezero bati. Beren lehenbiziko itxarongela routerra da, eta routerrak poolerako bide bat behar du VPN zerbitzarira seinalatzen duena, diseinuak bezeroaren trafikoa itzultzen ez badu behintzat.

Irakurri bidea bi norabideetan ezer aldatu aurretik. Itxarongelan, galdetu nukleoak zein interfaz erabiliko lukeen bezero baten helbiderako; bezeroan, galdetu zein bide erabiltzen duen LANeko helbide baterako.

Komando hauek itxarongelako aurreratze-erabakia eta bikoizketa agerian uzten duten bizilagun-sarrerak erakusten dituzte:

ip -4 route get 10.8.0.5
ip neigh show dev br-lan | grep 10.8
ip -4 route get 192.168.50.20

Lehen komandoak tunel interfazarekin erantzuten badu, itzulera-bidea existitzen da. LANeko interfazarekin erantzuten badu, routerrak uste du bezeroa kablean dagoela eta ARP egiten saiatuko da berarentzat.

Zubiratutako diseinuak badaude, baina aukeratu egin behar dira

Tunel bat LANera zubiratzea diseinu erreal bat da, bezeroek broadcastak jaso behar dituztenean edo segmentu bat suposatzen duten protokoloek aurkitu behar dituztenean erabiltzen dena. Zerbitzariak zubiratze-portaera hori eta harekin doan helbide-kudeaketa edukitzea eskatzen du.

Funtzionatzen ez duena emaitza zenbakiak kopiatuz imitatzea da. Zubirik gabeko pool partekatu batek gatazka ematen dizu aurkikuntzarik gabe, eta hori da bi antolaketen artean txarrena.

Aukeratu hirugarren geruza pool bereizi batekin, aplikazioak segmentua benetan behar ez badu, eta dokumentatu poola hurrengo administratzaileak ez dezan DHCP barrutia berrerabili txukuntasunagatik.