Prečo host v LAN odosiela ARP pre adresu klienta OpenVPN

Problémy s dosiahnuteľnosťou medzi hostom v LAN a klientom VPN často vedú späť k samotnému plánu adries. Dajte tomu hostu rozhranie na 10.0.100.0/22 a bude považovať každú adresu od 10.0.100.0 do 10.0.103.255 za priamo pripojenú, vrátane puly klientov ticho umiestnenej na 10.0.101.0/24. Odpoveď nikdy nejde do routera, pretože z pohľadu hosta do hry nevstupuje žiadny router. Paket je adresovaný susedovi a vyžiadaný na linke.

Tento mechanizmus stojí za celou rodinou hlásení: tunel je aktívny, server má trasu a host v LAN napriek tomu klienta nedosiahne.

Prefix /22, ktorý prehĺta /24

Čítajte prefix ako rozsah, nie ako reťazec. Prefix /22 obsahuje 1024 adries a 10.0.100.0/22 siaha od 10.0.100.0 do 10.0.103.255, takže pula na 10.0.101.0/24 leží celá vnútri. Chyba prejde revíziou, pretože prvé oktety puly vyzerajú inak ako prvé oktety LAN a iba tretí oktet prezradí vnorenie. Napíšte oba rozsahy číselne, kým ich vyhlásite za oddelené.

To isté vnorenie sa môže objaviť aj opačne. Pula, ktorá vyzerá voľná, pretože ju teraz nič nepoužíva, môže predsa spadnúť do prefixu, ktorý inzeruje nejaký router pobočky, a plán adries je jediný dokument, ktorý to ukazuje.

Priame pripojenie znamená ARP, nie routing

Keď host s rozhraním /22 odošle na 10.0.101.25, jadro porovná cieľ s prefixom rozhrania a nájde zhodu. Paket sa stane hľadaním suseda namiesto smerovaného paketu a na Ethernete je hľadanie suseda žiadosťou ARP pre túto adresu. Ak adresa patrí klientovi VPN za smerovanou bránou, žiadny host v LAN ju nevlastní, takže žiadosť zostane bez odpovede a pakety sa zahodia. Tunel za to nemôže a klient prevádzku nikdy neuvidí.

Preto porucha vyzerá asymetricky a občas prerušovane. Host VPN sa často do LAN dostane, pretože jeho vlastné trasy ukazujú správnym smerom, zatiaľ čo host v LAN nemôže odpovedať, a čokoľvek cachuje zastaranú položku ARP, nechá príznak blikať.

TUN, TAP a čo každý prenáša

Zariadenie TUN prenáša IP pakety a zariadenie TAP prenáša ethernetové rámce. Smerované spojenie TUN nemusí prenášať ARP, aby poskytlo dosiahnuteľnosť IP, a práve preto je neodpovedaná žiadosť vyššie očakávaná a nie pokazená. TAP s úmyselným mostom môže rozšíriť broadcastovú doménu a sprevádzkovať ARP, ale mení to, čo klient vidí, vyžaduje koncové body podporujúce rovnaké rámovanie a je prepracovaním sieťového modelu, nie opravou prekrývajúceho sa prefixu. Prepnutie smerovaného nasadenia na TAP, aby sa vyliečila chyba plánu adries, vymení malý problém za väčší.

Poznamenajte, kde sa žiadosť ARP objavila a ktorý systém ju vyslal, kým vyvodíte závery. Odosielateľ vám hovorí, čo si o cieli myslí, nie čo robí tunel.

Navrhnite pulu, ktorá sa nemôže prekrývať

Vyberte pulu mimo každý pripojený prefix a každý inzerovaný prefix pobočky a potom pridajte trasy, ktoré ju sprístupnia v oboch smeroch. Rozsah ako 10.8.0.0/24 v nevyužitej časti plánu sa ľahko premýšľa a LAN, ktorá sa k nemu musí dostať, dostane statickú trasu ukazujúcu na server VPN. Meňte spoločne pridelenie, inzerované trasy, povolené zdrojové adresy a pravidlá firewallu, pretože opisujú jeden návrh, a nie štyri nastavenia.

Zdrojový NAT na serveri môže pulu skryť za adresou smerovateľnou z LAN a je to legitímny nástroj migrácie. Prepísava aj zdroj, takže LAN stráca možnosť priraďovať spojenia jednotlivým klientom a uplatňovať pravidlá pre klienta.

Na prevzatie použite skutočne pridelenú adresu skutočného klienta a skutočnú požiadavku aplikácie z hosta v LAN a potom potvrďte, že odpoveď sleduje plánovanú bránu, a nie linku.