Kvifor ein LAN-vert ARPar etter adressa til ein OpenVPN-klient

Tilgjengelegeproblema mellom ein LAN-vert og ein VPN-klient går ofte tilbake til sjølve adresseplanen. Gje den verten eit grensesnitt på 10.0.100.0/22, og han handsamar kvar adresse frå 10.0.100.0 til 10.0.103.255 som direkte tilkopla, inkludert ein klientpool som stille ligg på 10.0.101.0/24. Svaret går aldri til ein ruttar, for frå synsvinkelen til verten er ingen ruttar involvert. Pakken er adressert til ein nabo og vert etterspurd på leidninga.

Den mekanismen ligg bak ein heil familie av rapportar: tunnelen er oppe, tenaren har ei rute, og LAN-verten kan framleis ikkje nå klienten.

Det /22 som svelgjer /24

Les prefikset som eit område, ikkje som ein streng. Eit /22 rommar 1024 adresser, og 10.0.100.0/22 strekkjer seg frå 10.0.100.0 til 10.0.103.255, så ein pool på 10.0.101.0/24 ligg heilt innanfor. Feilen overlever gjennomgangen fordi dei første oktettane til poolen ser annleis ut enn dei første oktettane til LANet, og berre den tredje oktetten avslører inneslutninga. Skriv begge områda numerisk ut før du erklærer dei åtskilde.

Den same inneslutninga kan oppstå omvendt. Ein pool som ser ledig ut fordi ingenting brukar han akkurat no, kan likevel falle innanfor eit prefiks som ein eller annan stadruttar annonserer, og adresseplanen er det einaste dokumentet som viser det.

Direkte tilkopla betyr ARP, ikkje ruting

Når ein vert med eit /22-grensesnitt sender til 10.0.101.25, samanliknar kjernen målet med prefikset til grensesnittet og finn eit treff. Pakken vert eit nabo-oppslag i staden for ein ruta pakke, og på Ethernet er nabo-oppslaget ei ARP-førespurnad for den adressa. Viss adressa høyrer til ein VPN-klient bak ein ruta gateway, eig ingen vert på LANet henne, så førespurnaden vert ståande ubesvart og pakkane vert kasta. Tunnelen har inga skuld, og klienten ser aldri trafikken.

Derfor ser feilen asymmetrisk ut og av og til tilbakevendande. VPN-verten kan ofte nå LANet fordi dei eigne rutene peikar rett veg, medan LAN-verten ikkje kan svare, og alt som cachar ein utdatert ARP-oppføring får symptomet til å flimre.

TUN, TAP og kva kvar av dei ber

Ei TUN-eining ber IP-pakkar, og ei TAP-eining ber Ethernet-rammer. Ei ruta TUN-lenke treng ikkje bere ARP for å levere IP-tilgjenge, og det er nettopp derfor den ubesvarte førespurnaden ovanfor er venta og ikkje øydelagd. TAP med ei medvite bru kan utvide kringkastingsdomenet og få ARP til å verke, men det endrar kva klienten kan sjå, krev endepunkt som støttar same innramming, og er ei nyutforming av nettverksmodellen snarare enn ein reparasjon for eit overlappande prefiks. Å byte ein ruta utplassering til TAP for å kurere ein adresseplanfeil byter eit lite problem mot eit større.

Noter kvar ARP-førespurnaden dukka opp og kva system som sende han, før du dreg konklusjonar. Avsendarren fortel deg kva han trur om målet, ikkje kva tunnelen gjer.

Design ein pool som ikkje kan overlappe

Vel ein pool utanfor kvart tilkopla prefiks og kvart annonsert stadprefiks, og legg deretter til rutene som gjer han tilgjengeleg i begge retningar. Eit område som 10.8.0.0/24 i ein ubrukt del av planen er lett å resonnere om, og eit LAN som treng å nå det, får ei statisk rute som peikar på VPN-tenaren. Endre tildelinga, dei annonserte rutene, dei tillatne kjeldeadressene og brannmurreglane saman, fordi dei skildrar ein design og ikkje fire innstillingar.

Source NAT på tenaren kan skjule poolen bak ei LAN-rutbar adresse, og det er eit legitimt migreringsverktøy. Det skriv òg om kjelda, så LANet mistar evna til å tilskrive tilkoplingar til enkeltklientar og bruke reglar per klient.

Bruk den ekte klienten si tildelte adresse og ei ekte applikasjonsførespurnad frå ein LAN-vert til aksepten, og stadfest deretter at svaret følgjer den planlagde gatewayen i staden for leidninga.