Proč host v LAN odesílá ARP pro adresu klienta OpenVPN

Problémy s dosažitelností mezi hostem v LAN a klientem VPN často vedou zpět k samotnému plánu adres. Dejte tomu hostu rozhraní na 10.0.100.0/22 a bude považovat každou adresu od 10.0.100.0 do 10.0.103.255 za přímo připojenou, včetně puly klientů tiše umístěné na 10.0.101.0/24. Odpověď nikdy nejde do routeru, protože z pohledu hosta žádný router nevstupuje do hry. Paket je adresován sousedovi a vyžádán na lince.

Tento mechanismus stojí za celou rodinou hlášení: tunel je aktivní, server má trasu a host v LAN přesto klienta nedosáhne.

Prefix /22, který polyká /24

Čtěte prefix jako rozsah, ne jako řetězec. Prefix /22 obsahuje 1024 adres a 10.0.100.0/22 sahá od 10.0.100.0 do 10.0.103.255, takže pula na 10.0.101.0/24 leží celá uvnitř. Chyba projde revizí, protože první oktety puly vypadají jinak než první oktety LAN a pouze třetí oktet prozradí vnoření. Napište oba rozsahy číselně, než je prohlásíte za oddělené.

Stejné vnoření se může objevit i obráceně. Pula, která vypadá volná, protože ji teď nic nepoužívá, může přesto spadat do prefixu, který inzeruje nějaký router pobočky, a plán adres je jediný dokument, který to ukazuje.

Přímé propojení znamená ARP, ne routing

Když host s rozhraním /22 odešle na 10.0.101.25, jádro porovná cíl s prefixem rozhraní a najde shodu. Paket se stane hledáním souseda místo směrovaného paketu a na Ethernetu je hledání souseda žádostí ARP pro tuto adresu. Pokud adresa patří klientovi VPN za směrovanou bránou, žádný host v LAN ji nevlastní, takže žádost zůstane bez odpovědi a pakety se zahodí. Tunel za to nemůže a klient provoz nikdy neuvidí.

Proto porucha vypadá asymetricky a občas přerušovaně. Host VPN se často do LAN dostane, protože jeho vlastní trasy ukazují správným směrem, zatímco host v LAN nemůže odpovědět, a cokoli cachuje zastaralou položku ARP, nechá příznak blikat.

TUN, TAP a co každý přenáší

Zařízení TUN přenáší IP pakety a zařízení TAP přenáší ethernetové rámce. Směrované spojení TUN nemusí přenášet ARP, aby poskytlo dosažitelnost IP, a právě proto je neodpovězená žádost výše očekávaná a ne rozbitá. TAP s úmyslným mostem může rozšířit broadcastovou doménu a zprovoznit ARP, ale mění to, co klient vidí, vyžaduje koncové body podporující stejné rámování a je přepracováním síťového modelu, nikoli opravou překrývajícího se prefixu. Přepnutí směrovaného nasazení na TAP, aby se vyléčila chyba plánu adres, vymění malý problém za větší.

Poznamenejte, kde se žádost ARP objevila a který systém ji vyslal, než vyvodíte závěry. Odesílatel vám říká, co si o cíli myslí, ne co dělá tunel.

Navrhněte pulu, která se nemůže překrývat

Vyberte pulu mimo každý připojený prefix a každý inzerovaný prefix pobočky a poté přidejte trasy, které ji zpřístupní v obou směrech. Rozsah jako 10.8.0.0/24 v nevyužité části plánu se snadno promýšlí a LAN, která se k němu musí dostat, dostane statickou trasu ukazující na server VPN. Měňte společně přidělení, inzerované trasy, povolené zdrojové adresy a pravidla firewallu, protože popisují jeden návrh, a ne čtyři nastavení.

Zdrojový NAT na serveru může pulu skrýt za adresou směrovatelnou z LAN a je to legitimní nástroj migrace. Přepisuje také zdroj, takže LAN ztrácí možnost přiřazovat spojení jednotlivým klientům a uplatňovat pravidla pro klienta.

Pro přejímku použijte skutečně přidělenou adresu skutečného klienta a skutečný požadavek aplikace z hosta v LAN a poté potvrďte, že odpověď sleduje plánovanou bránu, a ne linku.