De ce un host din LAN trimite ARP pentru adresa unui client OpenVPN

Problemele de accesibilitate dintre un host din LAN și un client VPN se trag adesea din planul de adresare însuși. Dă-i acelui host o interfață pe 10.0.100.0/22 și va trata fiecare adresă de la 10.0.100.0 până la 10.0.103.255 ca fiind conectată direct, inclusiv un pool de clienți plasat discret la 10.0.101.0/24. Răspunsul nu merge niciodată la un router, pentru că din punctul de vedere al hostului nu este implicat niciun router. Pachetul este adresat unui vecin și cerut pe fir.

Acest mecanism stă în spatele unei întregi familii de rapoarte: tunelul este activ, serverul are o rută, iar hostul din LAN tot nu poate atinge clientul.

Prefixul /22 care înghite /24

Citește prefixul ca pe un interval, nu ca pe un șir. Un /22 conține 1024 de adrese, iar 10.0.100.0/22 acoperă de la 10.0.100.0 până la 10.0.103.255, așa că un pool la 10.0.101.0/24 se află în întregime în interior. Eroarea supraviețuiește reviziei pentru că primii octeți ai pool-ului arată diferit de primii octeți ai LAN-ului, iar doar al treilea octet dezvăluie suprapunerea. Scrie ambele intervale numeric înainte de a le declara separate.

Aceeași suprapunere poate apărea invers. Un pool care pare liber pentru că nimic nu îl folosește acum poate cădea totuși în interiorul unui prefix anunțat de un router de site, iar planul de adresare este singurul document care arată asta.

Legătura directă înseamnă ARP, nu rutare

Când un host cu o interfață /22 trimite către 10.0.101.25, kernelul compară destinația cu prefixul interfeței și găsește o potrivire. Pachetul devine o rezolvare de vecin în loc de un pachet rutat, iar pe Ethernet rezolvarea de vecin este o cerere ARP pentru acea adresă. Dacă adresa aparține unui client VPN aflat în spatele unui gateway rutat, niciun host din LAN nu o deține, așa că cererea rămâne fără răspuns și pachetele sunt aruncate. Tunelul nu este vinovat, iar clientul nu vede niciodată traficul.

De aceea defecțiunea pare asimetrică și uneori intermitentă. Hostul VPN poate ajunge adesea în LAN pentru că propriile rute indică direcția corectă, în timp ce hostul din LAN nu poate răspunde, iar orice cache al unei intrări ARP vechi face simptomul să pâlpâie.

TUN, TAP și ce transportă fiecare

Un dispozitiv TUN transportă pachete IP, iar un dispozitiv TAP transportă cadre Ethernet. O legătură TUN rutată nu trebuie să transporte ARP pentru a oferi accesibilitate IP, și exact de aceea cererea fără răspuns de mai sus este de așteptat și nu un defect. TAP cu un bridge deliberat poate extinde domeniul de broadcast și poate face ARP să funcționeze, dar schimbă ce poate vedea clientul, cere puncte terminale care acceptă același cadru și este o reproiectare a modelului de rețea, nu o reparație pentru un prefix suprapus. A trece o implementare rutată pe TAP pentru a vindeca o eroare de plan de adresare schimbă o problemă mică pe una mai mare.

Notează unde a apărut cererea ARP și ce sistem a emis-o înainte de a trage concluzii. Expeditorul îți spune ce crede despre destinație, nu ce face tunelul.

Proiectează un pool care nu se poate suprapune

Alege un pool în afara fiecărui prefix conectat și a fiecărui prefix de site anunțat, apoi adaugă rutele care îl fac accesibil în ambele direcții. Un interval precum 10.8.0.0/24 într-o parte nefolosită a planului este ușor de raționat, iar un LAN care trebuie să îl atingă primește o rută statică îndreptată spre serverul VPN. Schimbă împreună alocarea, rutele anunțate, adresele sursă permise și regulile de firewall, pentru că descriu un singur proiect și nu patru setări.

NAT-ul sursă pe server poate ascunde pool-ul în spatele unei adrese rutabile din LAN, și este un instrument de migrare legitim. Rescrie și sursa, așa că LAN-ul pierde capacitatea de a atribui conexiuni unor clienți individuali și de a aplica reguli pe client.

Pentru acceptare, folosește adresa atribuită efectiv clientului real și o cerere reală de aplicație de la un host din LAN, apoi confirmă că răspunsul urmează gateway-ul planificat și nu firul.