Zašto host u LAN-u šalje ARP za adresu OpenVPN klijenta

Problemi s dosegljivošću između hosta u LAN-u i VPN klijenta često vode natrag do samog plana adresa. Dajte tom hostu sučelje na 10.0.100.0/22 i on će svaku adresu od 10.0.100.0 do 10.0.103.255 tretirati kao izravno povezanu, uključujući skupinu klijenata tiho smještenu na 10.0.101.0/24. Odgovor nikada ne ide usmjerivaču, jer sa stajališta hosta nije uključen nijedan usmjerivač. Paket je adresiran susjedu i traži se na žici.

Taj mehanizam stoji iza cijele obitelji izvještaja: tunel je aktivan, poslužitelj ima rutu, a host u LAN-u ipak ne može dosegnuti klijenta.

Prefiks /22 koji guta /24

Čitajte prefiks kao raspon, a ne kao niz znakova. Prefiks /22 sadrži 1024 adrese, a 10.0.100.0/22 proteže se od 10.0.100.0 do 10.0.103.255, pa skupina na 10.0.101.0/24 leži cijela unutar njega. Pogreška preživi pregled jer prvi okteti skupine izgledaju drukčije od prvih okteta LAN-a, a samo treći oktet otkriva sadržavanje. Zapišite oba raspona brojčano prije nego ih proglasite odvojenima.

Isto sadržavanje može se pojaviti i obrnuto. Skupina koja izgleda slobodna jer je trenutačno nitko ne koristi ipak može pasti unutar prefiksa koji oglašava neki usmjerivač lokacije, a plan adresa jedini je dokument koji to pokazuje.

Izravna veza znači ARP, a ne usmjeravanje

Kada host sa sučeljem /22 šalje na 10.0.101.25, jezgra uspoređuje odredište s prefiksom sučelja i pronalazi podudaranje. Paket postaje razrješavanje susjeda umjesto usmjerenog paketa, a na Ethernetu je razrješavanje susjeda ARP zahtjev za tu adresu. Ako adresa pripada VPN klijentu iza usmjerenog pristupnika, nijedan host u LAN-u je ne posjeduje, pa zahtjev ostaje bez odgovora i paketi se odbacuju. Tunel nije kriv, a klijent nikada ne vidi promet.

Zato kvar izgleda asimetrično i povremeno isprekidano. Host VPN često dosegne LAN jer njegove vlastite rute pokazuju u pravom smjeru, dok host u LAN-u ne može odgovoriti, i sve što predmemorira zastarjeli ARP zapis čini da simptom treperi.

TUN, TAP i što svaki prenosi

Uređaj TUN prenosi IP pakete, a uređaj TAP prenosi Ethernet okvire. Usmjerena TUN veza ne mora prenositi ARP da bi pružila dosegljivost IP-a, i upravo je zato neodgovoreni zahtjev gore očekivan, a ne pokvaren. TAP s namjernim mostom može proširiti broadcast domenu i osposobiti ARP, ali mijenja što klijent vidi, zahtijeva krajnje točke koje podržavaju isto uokvirivanje i prerada je mrežnog modela, a ne popravak preklapajućeg prefiksa. Prelazak usmjerene implementacije na TAP radi izlječenja pogreške plana adresa mijenja mali problem za veći.

Zabilježite gdje se ARP zahtjev pojavio i koji ga je sustav poslao prije nego izvedete zaključke. Pošiljatelj vam govori što misli o odredištu, a ne što tunel radi.

Projektirajte skupinu koja se ne može preklapati

Odaberite skupinu izvan svakog povezanog prefiksa i svakog oglašenog prefiksa lokacije, zatim dodajte rute koje je čine dosegljivom u oba smjera. Raspon poput 10.8.0.0/24 u neiskorištenom dijelu plana lako je promisliti, a LAN koji ga mora dosegnuti dobiva statičnu rutu koja pokazuje na VPN poslužitelj. Mijenjajte zajedno dodjelu, oglašene rute, dopuštene izvorne adrese i pravila vatrozida, jer opisuju jedan dizajn, a ne četiri postavke.

Izvorni NAT na poslužitelju može sakriti skupinu iza adrese usmjerive iz LAN-a i legitimno je migracijsko sredstvo. Prepisuje i izvor, pa LAN gubi mogućnost pripisivanja veza pojedinim klijentima i primjene pravila po klijentu.

Za prihvat upotrijebite stvarno dodijeljenu adresu stvarnog klijenta i stvarni zahtjev aplikacije s hosta u LAN-u, zatim potvrdite da odgovor slijedi planirani pristupnik, a ne žicu.