pfSense OpenVPN: dolazak do mreže iza drugog rutera

Vaš laptop dolazi do pfSense LAN-a preko VPN-a i još uvijek ne može doći do usluge dva hopa dalje, a razlika je jedna odluka o rutiranju po vlasniku. Tri uređaja moraju se složiti prije nego što paket završi svoje putovanje tamo i nazad: klijent, firewall i ruter koji zapravo posjeduje odredišnu mrežu. Propustite bilo koji od njih i simptom izgleda identično.

Pratite jedan paket kroz te tri odluke prije nego što promijenite pravilo, jer svaki vlasnik ima drugačiju kontrolu i drugačiji način kvara.

Jedan paket, tri odluke o rutiranju

Klijent odlučuje pripada li odredište tunelu i može odlučivati samo na osnovu onoga što zna: gurnuta ruta, lokalna ruta ili zadana ruta koja već pokriva sve. pfSense odlučuje kamo poslati paket dalje, što za mrežu iza drugog rutera znači statičku rutu kroz dostupan gateway na ispravnom interfejsu. Niži ruter odlučuje zna li put nazad do VPN pula, a ako ne zna, odgovor se odbacuje ili šalje na beskorisno mjesto. Svaka odluka nezavisna je od druge dvije.

Kvar bilo koje od njih daje isti korisnički izvještaj. Zato je redoslijed otklanjanja grešaka važniji od alata.

Dajte klijentu prefiks, a ne pretpostavku

Na pfSense SSL/TLS serveru s IPv4 tunelskom mrežom većom od /30, polje IPv4 Local network(s) distribuira rute klijentima kada se povežu. Dodajte niži prefiks tamo umjesto da se oslanjate na klijenta da ga izmisli. Zatim pročitajte stvarnu tablicu klijenta nakon povezivanja, jer profil s route-nopull ili filter ruta može zanemariti ono što je server poslao. Server može biti savršeno ispravan dok klijent ne instalira ništa.

Drugi načini rada servera i topologije imaju različita ograničenja, a politika po klijentu ili konekciji može promijeniti ono što određeni klijent prima. Provjerite na klijentu koji je važan, a ne na onom koji ste slučajno prvi testirali.

Usmjerite pfSense na interni ruter

Statičkoj ruti u pfSense-u treba definiran i dostupan gateway, a interfejs odabran za taj gateway mora biti onaj koji do njega stvarno dolazi, kako opisuje Netgateov vodič za statičke rute. U ilustrativnom rasporedu tranzitna veza je 192.168.77.1 na firewallu i 192.168.77.2 na internom ruteru, a servisna mreža je 172.16.30.0/25 iza njega. Ruta zatim imenuje prefiks i sljedeći hop, a ne adresu usluge. Korištenje adrese iz udaljene mreže kao gatewaya čest je način da se napravi ruta koja izgleda ispravno i ne prosljeđuje nigdje.

Davanje imena interfejsu ne opisuje mreže iza njega. Statička ruta je taj opis.

Udaljena strana mora znati pul

Niži ruter treba povratnu rutu za pul, u ovom primjeru 10.55.0.0/24 preko 192.168.77.1, osim ako zadanu rutu ili dinamički protokol već ne pruža. Gateway samog hosta usluge mora voditi prema tom ruteru, što je obično tačno kada je ruter njegov zadani gateway, a netačno kada je host ručno konfigurisan. Rutiranje po politici na firewallu također može nadjačati tablicu za određeni saobraćaj, pa provjerite odabire li pravilo drugi gateway prije nego zaključite da je ruta pogrešna.

Za ovaj dizajn nije potrebno prevođenje, a zadržavanje izvorne adrese klijenta vidljivom omogućava nižoj mreži da primijeni vlastitu politiku.

Za prihvatanje pratite jedan novi zahtjev kroz ulaz u tunel, interni izlaz firewalla i odgovor s odredišta. Ako se umjesto toga namjerno koristi prevođenje, zabilježite izvor koji niža mreža vidi i kako se očekuje da se odgovor vrati.

Sačuvajte plan s tri vlasnika uz dozvoljenu aplikaciju, kako bi sljedeći administrator mogao rekonstruisati put umjesto da ga ponovo otkriva.