Miks LAN-host saadab OpenVPN kliendi aadressile ARP-i
Kliendikogum LAN-i prefiksi sees paneb LAN-i saatma ARP-i aadressile, mida see ei suuda kätte saada. Lugege prefiksit, järgige otsese ühenduse otsust ja seejärel liigutage kogumit.
Kättesaadavusprobleemid LAN-hosti ja VPN-kliendi vahel viivad sageli tagasi aadressiplaani enda juurde. Andke sellele hostile liides 10.0.100.0/22 peal ja see käsitleb iga aadressi vahemikus 10.0.100.0 kuni 10.0.103.255 otseselt ühendatuna, sealhulgas kliendikogum, mis on vaikselt paigutatud 10.0.101.0/24 peale. Vastus ei lähe kunagi ruuterile, sest hosti vaatenurgast ei osale ükski ruuter. Pakett on adresseeritud naabrile ja küsitakse juhtmelt.
See mehhanism seisab terve teatmerühma taga: tunnel on üleval, serveril on marsruut ja LAN-host ei saa ikka kliendini.
/22, mis neelab /24
Lugege prefiksit vahemikuna, mitte stringina. /22 prefiks sisaldab 1024 aadressi ja 10.0.100.0/22 ulatub 10.0.100.0-st 10.0.103.255-ni, seega kogum 10.0.101.0/24 asub täielikult selle sees. Viga jääb ülevaatamisel püsima, sest kogumi esimesed oktetid näevad välja teisiti kui LAN-i esimesed oktetid, ja ainult kolmas okett paljastab sisaldumise. Kirjutage mõlemad vahemikud numbritena, enne kui kuulutate need eraldiseisvateks.
Sama sisaldumine võib ilmneda ka vastupidi. Kogum, mis näib vaba, sest keegi seda praegu ei kasuta, võib siiski langeda prefiksi sisse, mida mõni saidi ruuter kuulutab, ja aadressiplaan on ainus dokument, mis seda näitab.
Otsene ühendus tähendab ARP-i, mitte marsruutimist
Kui host /22 liidesega saadab aadressile 10.0.101.25, võrdleb kernel sihtkohta liidese prefiksiga ja leiab vastavuse. Paketist saab naabriotsing, mitte marsruuditud pakett, ja Ethernetis on naabriotsing selle aadressi ARP-päring. Kui aadress kuulub VPN-kliendile marsruuditud värava taga, ei oma seda ükski LAN-i host, seega jääb päring vastuseta ja paketid visatakse ära. Tunnel ei ole süüdi ja klient ei näe liiklust kunagi.
Seetõttu näib rike asümmeetriline ja mõnikord katkendlik. VPN-host jõuab sageli LAN-i, sest tema enda marsruudid osutavad õiges suunas, samal ajal kui LAN-host ei saa vastata, ja iga aegunud ARP-kirje vahemällu salvestamine paneb sümptomi vilkuma.
TUN, TAP ja mida kumbki kannab
TUN-seade kannab IP-pakette ja TAP-seade kannab Etherneti kaadreid. Marsruuditud TUN-ühendus ei pea ARP-i kandma, et pakkuda IP-kättesaadavust, ja just seetõttu on ülaltoodud vastuseta päring ootuspärane, mitte katki. TAP koos teadliku sillaga võib levialadomeeni laiendada ja ARP-i tööle panna, kuid see muudab seda, mida klient näeb, nõuab sama kaaderdust toetavaid lõpp-punkte ja on võrgumudeli ümberkujundus, mitte kattuvale prefiksile parandus. Marsruuditud juurutuse ümberlülitamine TAP-ile, et aadressiplaani viga ravida, vahetab väikese probleemi suurema vastu.
Märkige üles, kus ARP-päring ilmus ja milline süsteem selle saatis, enne kui järeldusi teete. Saatja ütleb teile, mida ta sihtkoha kohta arvab, mitte mida tunnel teeb.
Projekteerige kogum, mis ei saa kattuda
Valige kogum väljapoole igat ühendatud prefiksit ja igat kuulutatud saidi prefiksit, seejärel lisage marsruudid, mis teevad selle mõlemas suunas kättesaadavaks. Vahemik nagu 10.8.0.0/24 plaanis kasutamata osas on lihtne läbi mõelda, ja LAN, millel tuleb selleni jõuda, saab staatilise marsruudi, mis osutab VPN-serverile. Muutke koos jaotust, kuulutatud marsruute, lubatud lähteaadresse ja tulemüürireegleid, sest need kirjeldavad üht projekti, mitte nelja seadistust.
Source NAT serveris võib kogumi peita LAN-ist marsruuditava aadressi taha, ja see on seaduslik migreerimisvahend. See kirjutab ümber ka lähte, mistõttu LAN kaotab võimaluse omistada ühendusi üksikutele klientidele ja rakendada reegleid kliendi kohta.
Vastuvõtuks kasutage päris kliendi tegelikult määratud aadressi ja päris rakendusepäringut LAN-hostist, seejärel kinnitage, et vastus järgib kavandatud väravat, mitte juhet.