Pse një host i LAN-it bën ARP për adresën e një klienti OpenVPN
Një grup klientësh brenda prefiksit të LAN-it bën që LAN-i të bëjë ARP për një adresë që nuk mund ta arrijë. Lexo prefiksin, ndiq vendimin për lidhje të drejtpërdrejtë dhe më pas zhvendos grupin.
Problemet e arritshmërisë midis një hosti të LAN-it dhe një klienti VPN shpesh kthehen te vetë plani i adresave. Jepini atij hosti një ndërfaqe në 10.0.100.0/22 dhe ai do të trajtojë çdo adresë nga 10.0.100.0 deri në 10.0.103.255 si të lidhur drejtpërdrejt, duke përfshirë një grup klientësh të vendosur në heshtje në 10.0.101.0/24. Përgjigja nuk shkon kurrë te një ruter, sepse nga këndvështrimi i hostit nuk përfshihet asnjë ruter. Paketa adresohet për një fqinj dhe kërkohet në tel.
Ky mekanizëm qëndron pas një familjeje të tërë raportesh: tuneli është lart, serveri ka një rrugë dhe hosti i LAN-it prapë nuk e arrin klientin.
Prefiksi /22 që gëlltit /24
Lexojeni prefiksin si interval, jo si varg karakteresh. Një /22 përmban 1024 adresa, dhe 10.0.100.0/22 shtrihet nga 10.0.100.0 deri në 10.0.103.255, kështu që një grup në 10.0.101.0/24 ndodhet tërësisht brenda tij. Gabimi i mbijeton rishikimit sepse oktetët e parë të grupit duken ndryshe nga oktetët e parë të LAN-it, dhe vetëm okteti i tretë zbulon përfshirjen. Shkruajini të dy intervalet numerikisht përpara se t'i shpallni të ndarë.
E njëjta përfshirje mund të shfaqet edhe e kundërta. Një grup që duket i lirë sepse asgjë nuk e përdor tani mund të bjerë prapë brenda një prefiksi që shpall një ruter vendndodhjeje, dhe plani i adresave është i vetmi dokument që e tregon atë.
Lidhja e drejtpërdrejtë do të thotë ARP, jo rrugëtim
Kur një host me ndërfaqe /22 dërgon te 10.0.101.25, kerneli krahason destinacionin me prefiksin e ndërfaqes dhe gjen një përputhje. Paketa bëhet një zgjidhje fqinji në vend të një pakete të rrugëtuar, dhe në Ethernet zgjidhja e fqinjit është një kërkesë ARP për atë adresë. Nëse adresa i përket një klienti VPN pas një porte rrugëtuese, asnjë host i LAN-it nuk e zotëron atë, kështu që kërkesa mbetet pa përgjigje dhe paketat hidhen. Tuneli nuk ka faj, dhe klienti nuk e sheh kurrë trafikun.
Për këtë arsye dështimi duket asimetrik dhe ndonjëherë i ndërprerë. Hosti VPN shpesh arrin LAN-in sepse rrugët e tij tregojnë drejtimin e duhur, ndërsa hosti i LAN-it nuk mund të përgjigjet, dhe çdo memorie e një zëri të vjetër ARP e bën simptomën të pulsojë.
TUN, TAP dhe çfarë transporton secili
Një pajisje TUN transporton paketa IP, dhe një pajisje TAP transporton kuadro Ethernet. Një lidhje TUN e rrugëtuar nuk ka nevojë të transportojë ARP për të ofruar arritshmëri IP, dhe pikërisht për këtë kërkesa pa përgjigje më sipër pritet dhe nuk është defekt. TAP me një urë të qëllimshme mund të zgjerojë domenin e transmetimit dhe ta bëjë ARP të funksionojë, por ndryshon atë që klienti mund të shohë, kërkon skaje që mbështesin të njëjtin kornizim dhe është një ridizajnim i modelit të rrjetit, jo një riparim për një prefiks të mbivendosur. Kalimi i një vendosjeje të rrugëtuar në TAP për të shëruar një gabim plani adresash shkëmben një problem të vogël me një më të madh.
Shënoni ku u shfaq kërkesa ARP dhe cili sistem e emetoi para se të nxirrni përfundime. Dërguesi ju tregon çfarë mendon për destinacionin, jo çfarë bën tuneli.
Dizajnoni një grup që nuk mund të mbivendoset
Zgjidhni një grup jashtë çdo prefiksi të lidhur dhe çdo prefiksi vendndodhjeje të shpallur, më pas shtoni rrugët që e bëjnë të arritshëm në të dy drejtimet. Një interval si 10.8.0.0/24 në një pjesë të papërdorur të planit është i lehtë për t'u arsyetuar, dhe një LAN që duhet ta arrijë merr një rrugë statike që tregon te serveri VPN. Ndryshoni së bashku ndarjen, rrugët e shpallura, adresat burimore të lejuara dhe rregullat e murit të zjarrit, sepse përshkruajnë një dizajn të vetëm dhe jo katër cilësime.
NAT-i i burimit në server mund ta fshehë grupin pas një adrese të rrugëtueshme nga LAN-i, dhe është një mjet i ligjshëm migrimi. Ai rishkruan edhe burimin, kështu që LAN-i humbet aftësinë për t'i atribuar lidhjet klientëve individualë dhe për të zbatuar rregulla për klient.
Për pranimin, përdorni adresën e caktuar realisht të klientit të vërtetë dhe një kërkesë reale aplikacioni nga një host i LAN-it, më pas konfirmoni se përgjigja ndjek portën e planifikuar dhe jo telin.