VPN-kliento kun LAN-adreso ne estas en la LAN

La kliento konektiĝas, ricevas 10.50.0.200 kaj ne povas atingi la servilon ĉe 10.50.0.20, kvankam ambaŭ numeroj troviĝas en la sama /24. La kredo malantaŭ tiu agordo estas, ke adreso el la LAN-antatipo igas la klienton parto de la LAN. Ĝi ne faras tion. La kliento estas sur punkt-al-punkta ligilo, la servilo kredas ke la celo estas loka, kaj la mankanta peco estas najbara respondo, kiun neniu sendas.

La mito: sama antaŭsigno signifas saman segmenton

Adresa antaŭsigno diras al gastiganto, kiujn celojn ĝi povas atingi rekte kaj kiuj bezonas enkursigilon. Ĝi ne diras al la gastiganto, kiel la celo estas fizike alkroĉita, kaj ĝi certe ne garantias, ke la celo povas respondi peton sur la liga tavolo. Tiuj estas malsamaj demandoj, respondataj de malsamaj tabeloj sur la gastiganto. La masko respondas la unuan kaj la najbara tabelo la duan, kaj nur la unua estas sub via kontrolo de la VPN-flanko.

Kiam la servilo sendas al 10.50.0.200, ĝi komparas la celon kun sia propra masko, decidas ke la adreso estas on-link, kaj petas de la loka segmento la hardvaran adreson, kiu posedas ĝin. Tiu peto eliras sur la Ethernet-interfaco, kaj la VPN-kliento ne estas tie por aŭdi ĝin.

Nenio en la agordo de la kliento povas ripari tion de ĝia flanko. La responda vojo dependas de aparato en la LAN, kiu respondas nome de la kliento, aŭ de tio, ke la kliento havas adreson, kiun la servilo ne konsideras lokan.

Kion la loka gastiganto efektive faras kun la adreso

La konduto estas facile observebla kaj indas observon antaŭ ol vi ŝanĝos ion. Rigardu la najbaran tabelon sur LAN-gastiganto post kiam ĝi provis atingi la klienton: nekompleta aŭ malsukcesa rikordo estas la tuta diagnozo en unu linio. Tiu linio ankaŭ diras al vi, ke la difekto estas loka al la segmento kaj ne ie ene de la tunelo.

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

La vojserĉo raportos la celon kiel on-link tra la Ethernet-interfaco, kaj ĝuste tio estas la problemo. Se la najbara rikordo restas nekompleta dum la VPN-sesio funkcias, vi konfirmis, ke la mankanta peco estas solvo sur la liga tavolo, ne enkursigado aŭ fajroŝirma politiko.

Farigu la saman kontrolon de gastiganto en alia subreto kaj komparu. Gastiganto, kiu atingas la klienton tra enkursigilo, tute ne bezonas najbaran rikordon, kaj tiu diferenco estas la dezajna decido en miniaturo.

Kiel proxy ARP provizas sekvan salteton

Proxy ARP igas la enirejon respondi la peton de la liga tavolo nome de celo, kiun ĝi povas atingi tra alia interfaco. La LAN-gastiganto ricevas hardvaran adreson, sendas la kadron al la enirejo, kaj la enirejo plusendas la paketon en la VPN-sesion. El la vidpunkto de la gastiganto la kliento simple aspektas kvazaŭ ĝi estas malantaŭ la enirejo. Nenio pri la agordo de la kliento ŝanĝiĝas.

La RouterOS ARP-dokumentaro de MikroTik priskribas tiun uzon por dial-in-klientoj, kiuj prunteprenas la adresspacon de la konektita LAN. La mekanismo estas riparo de najbara solvo, kaj ĝi funkcias ĉar la enirejo vere troviĝas sur ambaŭ vojoj.

Tio ne estas la sama kiel ponti la klienton en la LAN. La enirejo ankoraŭ devas plusendi la paketon al la ĝusta aktiva sesio, kaj ĝia enkursigado kaj fajroŝirma politiko ankoraŭ devas permesi la servon. Proxy ARP ŝanĝas, kiu respondas la najbaran peton, ne kiu rajtas paroli.

Legu atente la modajn nomojn de la platformo. RouterOS apartigas proxy-arp de local-proxy-arp, kaj la dua traktas trafikon, kiu eniras kaj eliras tra la sama interfaco. Ili ne estas interŝanĝeblaj literumoj, kaj ebligi ambaŭ senkritike ne estas mallongigo.

Kion proxy ARP ne donas al vi

Ĝi ne provizas malkovron per broadcast aŭ multicast. Kliento, kiu devas trovi servon per broadcast, ankoraŭ malsukcesos, ĉar la enirejo plusendas unicast al la sesio kaj ne faras la klienton membro de la broadcast-domajno de la LAN. Malkovraj protokoloj, kiuj dependas de broadcast, estas ofta fonto de raportoj, ke ĝi funkcias por unu afero kaj ne por alia, en dezajnoj kun prunteprenitaj adresoj.

Ĝi ne rezervas la adreson. Se la prunteprenita numero ankaŭ troviĝas en DHCP-pool aŭ statika asigno, du aparatoj povas fini kun la sama adreso, kaj la rezulta konduto dependas de tempigo. Sukcesa ensaluto ne estas rezervo.

Kaj ĝi ne forigas la bezonon kunordigi kun la posedanto de la LAN. Proxy ARP-rikordo, kiu surprizas la posedanton de la adresa plano, estas subtena okazaĵo atendanta trankvilan semajnon.

Komparo kun aparte enkursigita pool

La alternativo estas doni al VPN-klientoj sian propran antaŭsignon kaj lasi LAN-gastigantojn enkursigi al ĝi. Tiam la servilo sendas off-link respondojn al sia enirejo, la enirejo enkursigas la antaŭsignon al la VPN-finpunkto, kaj najbara solvo sur la LAN-segmento tute ne bezonatas. Tio estas malpli da movaj partoj ol prunteprenita adreso plus proxy-respondo.

Tiu dezajno estas pli facile pripensebla kaj pli facile revidebla, ĉar la klienta gamo estas videble aparta de la LAN-gamo. Ĝi kostas vojon, revenan vojon kaj alirregulon, do la samajn aferojn, kiujn la proxy ARP-dezajno bezonas en malpli evidenta loko.

Elektu inter la modeloj konscie, ne hazarde. Proxy ARP riparas unu specifan rilaton; enkursigita pool forigas la bezonon de tiu riparo. Skribu, kiun vi elektis kaj kial, kaj la sekva homo ne devos retrovi tion el malsukcesa najbara rikordo.