Otvaranje VPN porta ne daje klijentima pristup LAN-u

Tunel se podiže, klijent se autentificira, a LAN iza gatewaya ostaje nevidljiv. Pravilo koje je to trebalo popraviti propušta VPN port i radi tačno kako je napisano, jer to pravilo uređuje pakete adresirane na sam gateway. Saobraćaj klijenta prema hostu iza gatewaya ima drugu destinaciju i drugi lanac. Uspješna prijava ne mijenja to koji od dva lanca kernel provjerava.

Dva lanca, dvije različite destinacije

Sudbinu paketa određuje to kuda ide, a ne kako je stigao. Saobraćaj adresiran na adresu gatewaya dostavlja se lokalno i ocjenjuje prema ulaznim pravilima. Saobraćaj koji gateway prosljeđuje dalje ocjenjuje se prema pravilima prosljeđivanja. Isti interfejs 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šaoca ne govori ništa o dopuštanju mreže iza njega. To su dvije odvojene odluke s odvojenim dokazima, a ime interfejsa na objema ih ne spaja.

Šta pravilo slušaoca zapravo dopušta

Paketi slušaoca završavaju u VPN procesu i to je ono što uopće omogućava uspostavljanje tunela. Stranica za administraciju gatewaya i lokalni dijagnostički odgovor također koriste vlastitu ulaznu putanju hosta, zato provjera prema gatewayu uspijeva dok sve iza njega pada. Oba rezultata su tačna i nijedan nije o LAN-u.

Kada proces dekapsulira saobraćaj klijenta za drugu destinaciju, paket ulazi u putanju prosljeđivanja i tamo mu treba dozvola. Uspješna autentifikacija rješava ko je klijent; ne rješava kuda klijent smije ići. Dva pitanja imaju različite vlasnike, različite dnevnike i različite poruke o grešci.

Testirajte s klijenta, nikada s gatewaya

Test napravljen na gatewayu slijedi vlastitu izlaznu putanju hosta i može proći dok je putanja prosljeđivanja zatvorena. Počnite test s klijenta i gledajte 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 destinacije ništa ne stigne, paket se odbacuje nakon dolaska, što upućuje na pravila prosljeđivanja ili na vlastito filtriranje destinacije. Ako se na tun0 ne pojavi ništa, klijent ga ni ne šalje u tunel, a problem je u rutiranju na klijentu, ne u politici na gatewayu. Uporedite 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 kernelu mora biti uključeno, filtarsko pravilo mora prihvatiti tok, a destinacija mora biti dostupna s putanjom za povratak odgovora. Ako bilo šta od toga nedostaje, iz perspektive klijenta tišina je 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žnim, a politika podrazumijevanog odbacivanja u drugom odbacuje pakete klijenta dok vlastiti saobraćaj gatewaya nastavlja raditi. Treći izlaz pokazuje zašto pravilo slušaoca nikada nije bilo problem.

Držite dva skupa pravila odvojeno u dokumentaciji

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

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

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