Zašto je podmreža iza OpenVPN klijenta nedostupna?

Pingovi na tunelsku adresu servera prolaze, klijentova vlastita tabela ruta izgleda ispravno, a LAN iza tog klijenta i dalje je nedostupan. Klijentova tabela rutiranja izgleda korektno, server ima rutu prema tunelu, a paketi i dalje nestaju. To je klasičan simptom layer-3 tunela koji nema pojma da je jedan od njegovih klijenata ujedno i gateway.

tun interfejs nema sljedeći skok po klijentu. Kernel vidi jedan interfejs sa mnogo peerova, pa se odluka o tome koji klijent treba dobiti paket za udaljeni LAN mora donijeti unutar OpenVPN procesa. Ta odluka se konfiguriše pomoću iroute, a bez nje paket nema kamo otići.

Server rutira po klijentu, a ne po interfejsu

Kada server treba poslati paket na tunelsku adresu klijenta, odgovor je nedvosmislen: adresa pripada sesiji tog klijenta. Kada je odredište cijela podmreža iza tog klijenta, adresa ne pripada nikome koga server poznaje, a kernel ruta prema tunelu samo kaže "kroz ovaj interfejs", ne govoreći koji peer.

OpenVPN to rješava internom tabelom rutiranja koja preslikava prefiks odredišta na određenog klijenta. Ta tabela se gradi od iroute zapisa, zato obična ruta na hostu servera nije dovoljna. Kernel ruta dovodi paket do tunelskog interfejsa; interno preslikavanje odlučuje koja sesija ga prima. Zato se popravka nikada ne pojavljuje u kernelovom izlazu ruta.

Ako preslikavanje nedostaje, paket stiže na server, poklapa se s tunelskom rutom i biva odbačen jer nijedan klijent ne polaže pravo na odredište. Ništa ne bilježi čistu grešku, zato kvar izgleda kao tiha crna rupa, a ne kao petlja rutiranja.

Pisanje iroute zapisa koji imenuje klijenta

iroute živi u datoteci konfiguracije specifičnoj za klijenta, a ne u glavnoj konfiguraciji servera. Usmjerite server na direktorij opcijom client-config-dir, zatim napravite datoteku čije je ime uobičajeno ime klijentovog certifikata i stavite prefiks unutra.

Za podružnicu čiji je LAN 10.20.0.0/24 i čije je uobičajeno ime certifikata branch-router, datoteka na toj putanji sadrži redak poput iroute 10.20.0.0 255.255.255.0. Glavnoj konfiguraciji treba samo opcija direktorija; prefiks živi kod klijenta.

Uobičajeno ime je krhki dio. Certifikat izdan s drugim subjektom, ili postava koja autentificira korisnike po korisničkom imenu dok je datoteka nazvana po certifikatu, stvara datoteku koja se nikada ne čita. Provjerite ime koje server stvarno prijavljuje za sesiju i razmotrite opciju koja neusklađenog klijenta pušta da ne uspije umjesto da se tiho poveže bez svojih ruta. Preimenovanje datoteke da odgovara certifikatu je petominutni popravak koji sprječava vrlo dugu večer.

Jedan klijent može posjedovati nekoliko prefiksa. Dodajte jedan iroute redak po mreži i držite popis uz ostale postavke tog klijenta da preslikavanje ostane provjerljivo.

Izgradnja povratnog puta u oba smjera

Dovođenje paketa do udaljenog LAN-a je pola posla. Klijent također mora slati promet tog LAN-a u tunel, što se obično radi guranjem rute klijentu: redak poput push "route 10.8.0.0 255.255.255.0" govori svakom klijentu kako doći do mreže na strani servera. Za podružnicu ekvivalentna ruta pokazuje na tunel za sve što treba dosegnuti na strani servera.

Povratni smjer treba vlasnika na dalekoj strani. Na toj strani netko mora znati put natrag: statička ruta na LAN ruteru koja usmjerava VPN pool na server, ili prevođenje adresa na serveru prije nego promet uđe u LAN. Statička ruta čuva originalne adrese vidljivima u zapisima i pravilima pristupa, ali traži suradnju vlasnika LAN-a; prevođenje je samostalno, ali skriva ko se stvarno povezao.

Prosljeđivanje mora biti omogućeno na hostu servera. Bez toga kernel prihvaća paket iz tunela i odbija ga proslijediti na LAN interfejs, što iz perspektive klijenta izgleda identično kao iroute koji nedostaje.

Provjera dostupnosti pravim sondama

Testirajte po slojevima umjesto da pingate drugi kraj i nagađate. Sa servera provjerite da interno preslikavanje za prefiks postoji i da kernel ruta pokazuje na tunel. S klijenta potvrdite da je gurnuta ruta instalirana i da je njegov zadani put za LAN adresu tunel.

Zatim promatrajte pakete. Snimanje na tunelskom interfejsu pokazuje prenosi li server prema klijentu, a snimanje na LAN interfejsu pokazuje prosljeđuje li. Ako prvo pokazuje pakete, a drugo ne, problem je u prosljeđivanju ili filtru; ako nijedno ne pokazuje ništa, pretraga je ranije neuspjela.

Dva servera spojena tunelom ponavljaju isto pravilo na obje strane: svakome treba iroute za pool onog drugog, i svakome trebaju ruta i prosljeđivanje koji čine put simetričnim. Rutiranje i politika su ovdje odvojeni pojmovi. Rutiranje odlučuje kamo paket može ići, a FORWARD pravilo odlučuje smije li, pa klijent s dva iroute retka može dosegnuti oba prefiksa osim ako filtar kaže drukčije.