Një klient VPN me adresë LAN nuk është në LAN

Klienti lidhet, merr 10.50.0.200 dhe nuk arrin serverin në 10.50.0.20 edhe pse të dy numrat janë në të njëjtën /24. Besimi pas asaj konfigurimi është se një adresë nga prefiksi i LAN-it e bën klientin pjesë të LAN-it. Nuk e bën. Klienti është në një lidhje pikë-për-pikë, serveri e konsideron destinacionin lokal, dhe pjesa që mungon është një përgjigje fqinji që askush nuk e dërgon.

Miti: i njëjti prefiks do të thotë i njëjti segment

Një prefiks adrese i thotë një hosti cilat destinacione arrin drejtpërdrejt dhe cilat kërkojnë një ruter. Nuk i thotë hostit se si destinacioni është i lidhur fizikisht, dhe sigurisht nuk garanton se destinacioni mund t’i përgjigjet një kërkese në shtresën e lidhjes. Këto janë pyetje të ndryshme, të cilave u përgjigjen tabela të ndryshme në host. Maska i përgjigjet të parës dhe tabela e fqinjëve të dytës, dhe vetëm e para është nën kontrollin tuaj nga ana e VPN.

Kur serveri dërgon në 10.50.0.200, krahason destinacionin me maskën e vet, vendos që adresa është on-link, dhe pyet segmentin lokal për adresën e harduerit që e zotëron. Ajo kërkesë del nga ndërfaqja Ethernet, dhe klienti VPN nuk është atje për ta dëgjuar.

Asgjë në konfigurimin e klientit nuk mund ta rregullojë këtë nga ana e tij. Rruga e përgjigjes varet nga fakti që një pajisje në LAN përgjigjet në emër të klientit, ose nga fakti që klienti ka një adresë që serveri nuk e konsideron lokale.

Çfarë bën në të vërtetë hosti lokal me adresën

Sjellja është e lehtë për t’u vëzhguar dhe ia vlen të vëzhgohet përpara se të ndryshoni gjithçka. Shikoni tabelën e fqinjëve në një host të LAN-it pasi ka provuar të arrijë klientin: një hyrje jo e plotë ose e dështuar është i gjithë diagnozi në një rresht. Ai rresht ju thotë gjithashtu që defekti është lokal për segmentin dhe jo diku brenda tunelit.

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

Kërkimi i rrugës do ta raportojë destinacionin si on-link përmes ndërfaqes Ethernet, dhe ky është pikërisht problemi. Nëse hyrja e fqinjit mbetet jo e plotë ndërsa sesioni VPN është aktiv, ju keni konfirmuar që pjesa që mungon është zgjidhja në shtresën e lidhjes dhe jo rrugëtimi ose politika e murit të zjarrit.

Kryeni të njëjtin kontroll nga një host në një nënrrjetë tjetër dhe krahasoni. Një host që e arrin klientin përmes një ruteri nuk ka fare nevojë për hyrje fqinji, dhe ai ndryshim është vendimi i projektimit në miniaturë.

Si e siguron proxy ARP hapin tjetër

proxy ARP e bën gateway të përgjigjet kërkesës së shtresës së lidhjes në emër të një destinacioni që mund ta arrijë përmes një ndërfaqeje tjetër. Hosti i LAN-it merr një adresë hardueri, e dërgon kornizën te gateway, dhe gateway e përcjell paketën në sesionin VPN. Nga këndvështrimi i hostit klienti thjesht duket se është pas gateway. Asgjë në konfigurimin e klientit nuk ndryshon.

Dokumentacioni i RouterOS për ARP nga MikroTik përshkruan atë përdorim për klientët dial-in që huazojnë hapësirën e adresave të LAN-it të lidhur. Mekanizmi është një riparim i zgjidhjes së fqinjëve, dhe funksionon sepse gateway është vërtet në të dyja rrugët.

Kjo nuk është e njëjtë me urëzimin e klientit brenda LAN-it. Gateway duhet ende ta përcjellë paketën në sesionin e duhur aktiv, dhe rrugëtimi dhe politika e tij e murit të zjarrit duhet ende ta lejojnë shërbimin. proxy ARP ndryshon kush i përgjigjet kërkesës së fqinjit, jo kush ka leje të flasë.

Lexoni me kujdes emrat e modalitetit të platformës. RouterOS e ndan proxy-arp nga local-proxy-arp, dhe i dyti trajton trafikun që hyn dhe del përmes të njëjtës ndërfaqe. Këto nuk janë drejtshkrime të këmbyeshme, dhe aktivizimi i të dyjave pa dallim nuk është shkurtore.

Çfarë nuk ju jep proxy ARP

Ai nuk ofron zbulim përmes broadcast ose multicast. Një klient që duhet të gjejë një shërbim përmes broadcast do të dështojë gjithsesi, sepse gateway e përcjell unicast në sesion dhe nuk e bën klientin anëtar të domenit të broadcast të LAN-it. Protokollet e zbulimit që mbështeten në broadcast janë një burim i zakonshëm i raporteve se funksionon për një gjë dhe jo për një tjetër në projektet me adresa të huazuara.

Ai nuk e rezervon adresën. Nëse numri i huazuar ndodhet gjithashtu në një pishinë DHCP ose në një caktim statik, dy pajisje mund të përfundojnë me të njëjtën adresë dhe sjellja që rezulton varet nga koha. Një hyrje e suksesshme nuk është rezervim.

Dhe nuk e heq nevojën për t’u koordinuar me pronarin e LAN-it. Një hyrje proxy ARP që e surprizon pronarin e planit të adresave është një incident mbështetjeje që pret një javë të qetë.

Krahasim me një pishinë të rrugëtuar veçmas

Alternativa është t’u jepet klientëve VPN prefiksi i tyre dhe t’i lini hostet e LAN-it të rrugëtojnë drejt tij. Atëherë serveri dërgon përgjigje off-link te gateway i tij, gateway e rrugëton prefiksin drejt pikës fundore të VPN, dhe në segmentin e LAN-it nuk nevojitet fare zgjidhje fqinjësh. Kjo është më pak pjesë lëvizëse sesa një adresë e huazuar plus një përgjigje proxy.

Ai projekt është më i lehtë për t’u menduar dhe më i lehtë për t’u audituar, sepse diapazoni i klientëve është dukshëm i ndarë nga diapazoni i LAN-it. Kushton një rrugë, një rrugë kthimi dhe një rregull aksesi, të njëjtat gjëra që projekti me proxy ARP i kërkon në një vend më pak të dukshëm.

Zgjidhni mes modeleve me qëllim dhe jo rastësisht. proxy ARP riparon një marrëdhënie të caktuar; një pishinë e rrugëtuar e shmang nevojën për atë riparim. Shkruani cilën zgjodhët dhe pse, dhe personi tjetër nuk do të duhet ta rizbulojë atë nga një hyrje fqinji e dështuar.