Otvaranje VPN porta ne daje klijentima pristup LAN mreži

Tunel se diže, klijent se autentificira, a LAN iza prolaza ostaje nevidljiv. Pravilo koje je to trebalo popraviti propušta VPN port i radi točno kako je napisano, jer to pravilo uređuje pakete adresirane na sam prolaz. Promet klijenta prema računalu iza prolaza ima drugo odredište i drugi lanac. Uspješna prijava ne mijenja to koji od dvaju lanaca jezgra provjerava.

Dva lanca, dva različita odredišta

Sudbinu paketa određuje kamo ide, a ne kako je stigao. Promet adresiran na adresu prolaza dostavlja se lokalno i ocjenjuje prema ulaznim pravilima. Promet koji prolaz prosljeđuje dalje ocjenjuje se prema pravilima prosljeđivanja. Isto sučelje tunela može proizvesti obje vrste paketa, zato jedno pravilo ne može pokriti oba posla.

Cijeli mit u jednoj rečenici: dopuštanje slušatelja ne govori ništa o dopuštanju mreže iza njega. To su dvije odvojene odluke s odvojenim dokazima, a naziv sučelja na objema ne spaja ih.

Što pravilo slušatelja zapravo dopušta

Paketi slušatelja završavaju u VPN procesu i to je ono što uopće omogućuje uspostavu tunela. Stranica za upravljanje prolazom i lokalni dijagnostički odgovor također koriste vlastiti ulazni put računala, zato provjera prema prolazu uspijeva dok sve iza njega pada. Oba su rezultata točna i nijedan nije o LAN mreži.

Kada proces dekapsulira promet klijenta za drugo odredište, paket ulazi u put prosljeđivanja i ondje treba dopuštenje. Uspješna autentifikacija rješava tko je klijent; ne rješava kamo klijent smije ići. Dva pitanja imaju različite vlasnike, različite zapise i različite poruke o pogrešci.

Testirajte s klijenta, nikada s prolaza

Test napravljen na prolazu slijedi vlastiti izlazni put računala i može proći dok je put prosljeđivanja zatvoren. Počnite test s klijenta i promatrajte oba kraja toka.

nc -vz 10.40.7.25 445
tcpdump -ni tun0 host 10.40.7.25

Ako se zahtjev pojavi na tun0, a do odredišta ništa ne stigne, paket se odbacuje nakon dolaska, što upućuje na pravila prosljeđivanja ili na vlastito filtriranje odredišta. Ako se na tun0 ne pojavi baš ništa, klijent ga ni ne šalje u tunel, a problem je u usmjeravanju na klijentu, ne u politici na prolazu. Usporedite to sa zahtjevom koji ispravno izađe i ništa ne vrati, što je slučaj povratnog puta.

Prosljeđivanje traži tri stvari, ne jednu

Prosljeđivanje u jezgri mora biti uključeno, filtarsko pravilo mora prihvatiti tok, a odredište mora biti dostupno s putem za povratak odgovora. Ako bilo što od toga nedostaje, tišina je iz perspektive klijenta ista.

sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
sudo iptables -S INPUT

Čitajte tri izlaza zajedno. Nula u prvom čini druga dva nevažnima, a politika zadanog odbacivanja u drugom odbacuje pakete klijenta dok vlastiti promet prolaza nastavlja raditi. Treći izlaz pokazuje zašto pravilo slušatelja nikada nije bilo problem.

Držite dva skupa pravila odvojeno u dokumentaciji

Napišite pravilo slušatelja i pravilo proslijeđene usluge na odvojenim retcima, s odvojenim vlasnicima i razlozima. Kada se VPN port promijeni ili se objavi nova usluga, to razdvajanje sprječava da jedna promjena tiho proširi drugu.

Umjesto da svakog autentificiranog partnera tretirate kao pouzdanog člana LAN mreže, koristite uska pravila za one raspone klijenata i usluge kojima su potrebna. Bilješke o prosljeđivanju StrongSwan opisuju stranu povratne rute i prevođenja iste granice, što je opet treća odluka.

Konačno, držite slojeve uspravnima kada korisnik bude odbijen. Ako zahtjev stigne do računala, a aplikacija odbije račun, popravite dopuštenje aplikacije na tom sloju; širenje prosljeđivanja ne može dati vjerodajnicu za dijeljenje datoteka i proširit će pristup svima ostalima koji se uspješno povežu.