LAN usmjerivač i VPN klijent: dva uređaja, dvije tablice usmjeravanja

Dva uređaja prosljeđuju paket i svaki drži svoju tablicu. LAN usmjerivač zna da udaljeni prefiks pripada VPN klijentu, a VPN klijent zna kako do tog prefiksa doći kroz svoj tunel. Konfigurirajte samo prvu tablicu i paket stigne na računalo bez odgovarajuće rute, pa ponovno izađe preko zadane rute. To je cijela greška, i s LAN strane izgleda kao petlja usmjeravanja, jer gotovo i jest.

Nacrtajte dva skoka prije nego dotaknete rutu

Uzmite ilustrativan raspored: LAN hostovi na 192.168.50.0/24, obični usmjerivač na 192.168.50.1, namjenski klijent na 192.168.50.15 i udaljeni LAN na 10.60.0.0/24 dostupan samo kroz tunel koji taj klijent drži. Nijedan od dvaju privatnih raspona ne preklapa se s drugim, a tunel ima vlastiti plan adresa.

Oba su privatna raspona važna jer određuju koja stanica može odgovoriti. Udaljena strana vidjet će paket kako dolazi s tunelske adrese klijenta, a njezin odgovor mora pronaći put natrag na 192.168.50.0/24. Ako je konfiguriran samo izlazni smjer, zahtjev može raditi dok odgovor nestaje.

Korak 1: usmjerite usmjerivač prema klijentu, ne prema tunelu

Na LAN usmjerivaču dodajte odredišnu rutu čiji je sljedeći skok LAN adresa klijenta:

ip route add 10.60.0.0/24 via 192.168.50.15
ip route get 10.60.0.55

Taj zapis kaže „dostavi to stroju koji može tunelirati“. Ne govori ništa o tome kako se tunel gradi i ne zamjenjuje klijentovu vlastitu rutu. Na upravljanom usmjerivaču ekvivalent živi na stranici statičkih ruta uređaja; na Linux usmjerivaču pripada konfiguraciji sučelja koje posjeduje LAN, a ne ljusci koju ćete zatvoriti.

Provjerite odgovor druge naredbe. Ako prijavljuje klijenta kao gateway, a LAN sučelje kao device, prvi je skok ispravan i ostatak posla je na drugom stroju.

Korak 2: dajte klijentu vlastitu rutu na strani tunela

Klijent sada prima paket za 10.60.0.0/24 i pregledava svoju tablicu. Ako je njegova konfiguracija tunela instalirala rutu za taj prefiks, paket se nastavlja šifrirano. Ako nije, paket odgovara običnoj zadanoj ruti i vraća se na 192.168.50.1, koji ga ponovno šalje klijentu.

Pogledajte prije nego nešto dodate:

ip route show table all | grep -E "10\.60\.0\.0/24|default"
sysctl net.ipv4.ip_forward

Nedostajuća ruta prefiksa u svim tablicama je nalaz koji tražite. Dodajte ju kroz vlastitu konfiguraciju tunela, tako da ju sljedeće ponovno povezivanje ponovno instalira; ručna ip route add nestaje sa sesijom i vraća grešku u najnezgodnijem trenutku. Sljedeći je skok tunelsko sučelje ili adresa koju VPN dodjeljuje kao svog partnera, ovisno o klijentu, a adresa partnera treba dolaziti iz trenutačnog profila, ne iz stare bilješke.

Petlja, kada se pojavi, u praksi nije beskonačna: TTL pada pri svakom prolazu i paket umire s porukom o prekoračenju vremena. Zato ponavljani traceroute može upućivati na ciklus, dok klijent koji jednostavno ne prosljeđuje isti paket tiho odbacuje.

Korak 3: dopustite prosljeđivanje i odaberite povratni put

Primanje i prosljeđivanje različita su dopuštenja. net.ipv4.ip_forward=1 na klijentu dopušta tranzit na razini jezgre, a vatrozidno pravilo to još mora dopustiti između LAN sučelja i tunela. Pravilo koje dopušta pristup vlastitoj upravljačkoj stranici klijenta neće dopustiti tranzit prema udaljenom LAN-u, a tu je razliku lako propustiti kada isti host lokalno odgovara na ping.

Udaljena strana ima zrcalni problem. Mora znati da je 192.168.50.0/24 dostupan kroz ovog autentificiranog klijenta. S OpenVPN to obično znači rutu po klijentu koju gura konfiguracija poslužitelja, ili datoteku specifičnu za klijenta na poslužitelju koja deklarira LAN iza klijenta. Bez toga udaljeni LAN ili odbacuje odgovor ili ga šalje na vlastiti zadani pristupnik, to jest na internet.

Prevođenje izvora alternativa je kada se LAN prefiks ne može oglašavati. Ograničeno masquerade pravilo na klijentu prepisuje izvor na tunelsku adresu, a odgovori se tada vraćaju prirodno. Također skriva koji je LAN host poslao zahtjev i samo po sebi ne dopušta udaljenoj strani pokretanje veza prema unutra. Odaberite tu razmjenu svjesno, umjesto da dodate sveobuhvatno masquerade i otkrijete nuspojavu kasnije.

Korak 4: učinite obje odluke trajnima, a zatim testirajte stvarni put

Svaka ruta ima vlasnika, a vlasnik je konfiguracija koja se obnavlja pri podizanju ili pri ponovnom povezivanju. Na usmjerivaču to može biti zapis statičke rute; na klijentu to može biti VPN profil, NetworkManager ili systemd-networkd. Provjerite ponovnim povezivanjem tunela i ponovnim pokretanjem klijenta, pa ponovno pročitajte tablicu umjesto da vjerujete izmjeni.

Sačuvajte netaknutom zadanu rutu koja nosi vanjsku vezu tunela. Njezina zamjena radi „pojednostavljenja“ postava prekida šifrirani put prije nego što se njime može koristiti ikakav unutarnji promet, a simptom je tunel koji se nakon promjene nikad više ne uspostavlja.

Testirajte s običnog LAN hosta, ne s klijenta, jer zahtjev nastao na klijentu nikad ne vježba prvi skok usmjerivača. Dohvatite uslugu koja postoji samo na udaljenom LAN-u i potvrdite tijelo odgovora, pa pogledajte brojače ili zapisnike klijenta da vidite tranzit. Unutarnji traceroute s privatnim skokovima dokazuje prosljeđivanje, ne šifriranje: vanjski je put zasebno promatranje, i samo brojači sučelja tunela pokazuju što je kroz njega izašlo.