Zakaj gostitelj v LAN pošlje ARP za naslov odjemalca OpenVPN

Težave z dosegljivostjo med gostiteljem v LAN in odjemalcem VPN se pogosto vračajo k samemu načrtu naslovov. Temu gostitelju dajte vmesnik na 10.0.100.0/22 in vsak naslov od 10.0.100.0 do 10.0.103.255 bo obravnaval kot neposredno povezan, vključno s skupino odjemalcev, tiho postavljeno na 10.0.101.0/24. Odgovor nikoli ne gre na usmerjevalnik, ker z vidika gostitelja ni vključen noben usmerjevalnik. Paket je naslovljen na soseda in zahtevan na žici.

Ta mehanizem stoji za celo družino poročil: tunel je vzpostavljen, strežnik ima pot, gostitelj v LAN pa odjemalca še vedno ne doseže.

Predpona /22, ki pogoltne /24

Predpono berite kot obseg, ne kot niz. Predpona /22 vsebuje 1024 naslovov, 10.0.100.0/22 pa sega od 10.0.100.0 do 10.0.103.255, zato skupina na 10.0.101.0/24 leži v celoti znotraj nje. Napaka preživi pregled, ker prvi okteti skupine izgledajo drugače kot prvi okteti LAN, in le tretji oktet razkrije vsebovanje. Oba obsega zapišite številsko, preden ju razglasite za ločena.

Isto vsebovanje se lahko pojavi tudi v obratni smeri. Skupina, ki je videti prosta, ker je nihče ne uporablja, lahko vseeno pade znotraj predpone, ki jo oglašuje kak usmerjevalnik lokacije, in načrt naslovov je edini dokument, ki to pokaže.

Neposredna povezava pomeni ARP, ne usmerjanja

Ko gostitelj z vmesnikom /22 pošlje na 10.0.101.25, jedro primerja cilj s predpono vmesnika in najde ujemanje. Paket postane iskanje soseda namesto usmerjenega paketa, na Ethernetu pa je iskanje soseda zahteva ARP za ta naslov. Če naslov pripada odjemalcu VPN za usmerjenimi vrati, ga noben gostitelj v LAN ne poseduje, zato zahteva ostane brez odgovora in paketi se zavržejo. Tunel ni kriv, in odjemalec prometa nikoli ne vidi.

Zato je okvara videti asimetrična in občasno prekinjena. Gostitelj VPN pogosto doseže LAN, ker njegove lastne poti kažejo v pravo smer, medtem ko gostitelj v LAN ne more odgovoriti, in vse, kar predpomni zastarel vnos ARP, povzroči utripanje simptoma.

TUN, TAP in kaj prenaša vsak

Naprava TUN prenaša pakete IP, naprava TAP pa prenaša okvire Ethernet. Usmerjena povezava TUN ne potrebuje prenosa ARP za dosegljivost IP, in prav zato je neodgovorjena zahteva zgoraj pričakovana in ne pokvarjena. TAP s premišljenim mostom lahko razširi oddajno domeno in omogoči delovanje ARP, vendar spremeni, kaj odjemalec vidi, zahteva končne točke, ki podpirajo isto uokvirjanje, in je preoblikovanje omrežnega modela, ne popravilo prekrivajoče se predpone. Preklop usmerjene uvedbe na TAP za ozdravitev napake načrta naslovov zamenja majhen problem za večjega.

Zapišite, kje se je zahteva ARP pojavila in kateri sistem jo je poslal, preden sklepate. Pošiljatelj vam pove, kaj misli o cilju, ne kaj počne tunel.

Načrtujte skupino, ki se ne more prekrivati

Izberite skupino zunaj vsake povezane predpone in vsake oglaševane predpone lokacije, nato dodajte poti, ki jo naredijo dosegljivo v obe smeri. Obseg, kot je 10.8.0.0/24 v neuporabljenem delu načrta, je lahko razumeti, in LAN, ki ga mora doseči, dobi statično pot, ki kaže na strežnik VPN. Skupaj spremenite dodelitev, oglaševane poti, dovoljene izvorne naslove in pravila požarnega zidu, ker opisujejo eno zasnovo in ne štirih nastavitev.

Izvorni NAT na strežniku lahko skrije skupino za naslovom, usmerljivim iz LAN, in je zakonito orodje za selitev. Prepiše tudi vir, zato LAN izgubi možnost pripisovanja povezav posameznim odjemalcem in uveljavljanja pravil na odjemalca.

Za prevzem uporabite dejansko dodeljeni naslov resničnega odjemalca in resnično zahtevo aplikacije z gostitelja v LAN, nato potrdite, da odgovor sledi načrtovanim vratom in ne žici.