Otvorenie portu VPN nedá klientom prístup do LAN

Tunel sa zdvihne, klient sa overí, ale LAN za bránou zostáva neviditeľná. Pravidlo, ktoré to malo opraviť, prepúšťa port VPN a funguje presne tak, ako je napísané, lebo to pravidlo upravuje pakety adresované samotnej bráne. Premávka klienta k hostiteľovi za bránou má iný cieľ a inú reťaz. Úspešné prihlásenie nemení, ktorú z dvoch reťazí jadro prezerá.

Dve reťaze, dva rôzne ciele

Osud paketu určuje to, kam ide, nie to, ako prišiel. Premávka na adresu brány sa doručí lokálne a vyhodnotí podľa vstupných pravidiel. Premávka, ktorú brána preposiela ďalej, sa vyhodnocuje podľa pravidiel preposielania. To isté rozhranie tunela môže vytvárať oba druhy paketov, preto jedno pravidlo nemôže pokryť obe úlohy.

Celý mýtus v jednej vete: povolenie poslucháča nehovorí nič o povolení siete za ním. Sú to dve oddelené rozhodnutia s oddelenými dôkazmi a názov rozhrania na oboch ich nezlúči.

Čo pravidlo poslucháča skutočne prepúšťa

Pakety poslucháča končia v procese VPN, a to vôbec umožňuje vznik tunela. Administračná stránka brány i lokálna diagnostická odpoveď používajú vlastnú vstupnú cestu hostiteľa, preto test na bránu prejde, kým všetko za ňou zlyhá. Oba výsledky sú správne a ani jeden nie je o LAN.

Keď proces dekapsuluje premávku klienta pre iný cieľ, paket vstúpi na cestu preposielania a tam potrebuje povolenie. Úspešná autentifikácia rozhoduje, kto je klient; nerozhoduje, kam smie ísť. Obe otázky majú iných vlastníkov, iné záznamy a iné chybové hlásenia.

Testujte z klienta, nikdy z brány

Test vytvorený na bráne sleduje vlastnú výstupnú cestu hostiteľa a môže prejsť, aj keď je preposielaná cesta zavretá. Začnite test z klienta a sledujte oba konce toku.

nc -vz 10.40.7.25 445
tcpdump -ni tun0 host 10.40.7.25

Ak sa požiadavka objaví na tun0 a do cieľa nič nedorazí, paket sa po doručení zahodí, čo ukazuje na pravidlá preposielania alebo na vlastné filtrovanie cieľa. Ak sa na tun0 neobjaví vôbec nič, klient ho do tunela ani neposiela a problém je v smerovaní na klientovi, nie v politike brány. Porovnajte to s požiadavkou, ktorá správne odíde a nič nevráti, čo je prípad spiatočnej cesty.

Preposielanie potrebuje tri veci, nie jednu

Preposielanie v jadre musí byť zapnuté, filtrovacie pravidlo musí tok prijať a cieľ musí byť dosiahnuteľný s cestou pre návrat odpovede. Ak chýba čokoľvek z toho, ticho z pohľadu klienta je rovnaké.

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

Čítajte tri výstupy spolu. Nula v prvom robí ďalšie dva nepodstatnými a politika predvoleného zahadzovania v druhom zahadzuje pakety klienta, kým vlastná premávka brány ďalej funguje. Tretí výstup ukazuje, prečo pravidlo poslucháča nikdy nebolo problémom.

Držte obe sady pravidiel v dokumentácii oddelene

Napíšte pravidlo poslucháča a pravidlo preposielanej služby na samostatné riadky s oddelenými vlastníkmi a dôvodmi. Keď sa port VPN zmení alebo sa publikuje nová služba, toto oddelenie bráni tomu, aby jedna zmena potichu rozšírila druhú.

Namiesto toho, aby ste každého overeného partnera brali ako dôveryhodného člena LAN, používajte úzke pravidlá pre tie rozsahy klientov a služby, ktoré ich potrebujú. Poznámky k preposielaniu StrongSwan opisujú stranu spiatočnej trasy a prekladu tej istej hranice, čo je opäť tretie rozhodnutie.

Napokon držte vrstvy rovno, keď je používateľ odmietnutý. Ak požiadavka dorazí na hostiteľa a aplikácia odmietne účet, opravte oprávnenie aplikácie na tej vrstve; rozšírenie preposielania nemôže dodať prihlasovacie údaje na zdieľanie súborov a rozšíri prístup všetkým ostatným, ktorí sa úspešne pripoja.