VPN klienti dosiahnu na server, ale nie do siete LAN: ktoré riešenie?

Klient pingne adresu tunela servera OpenVPN a dostane odpoveď, potom skúsi hostiteľa v sieti LAN servera a nedostane nič. Toto rozdelenie výrazne zúžuje poruchu: tunel je hore, preposielanie pravdepodobne funguje a odpoveď odchádza dverami, ktoré nevedú späť. Existujú tri riešenia a to správne závisí od toho, čo ovládate a čoho ste ochotní sa vzdať. Odpovedzte na tri otázky nižšie po poradí a voľba prestane byť vecou vkusu.

Najprv zistite, ktorý smer je rozbitý

Požiadavka prichádza na rozhranie tunela so zdrojovou adresou z fondu VPN. Server ju prepošle hostiteľovi v sieti LAN a ten odpovie bráne, ktorú určí jeho vlastná tabuľka, zvyčajne routeru siete LAN. Ak router nemá trasu do fondu, odpoveď tam zomrie alebo blúdi smerom k internetu.

Otestujte oba stroje, než niektorý upravíte. Opýtajte sa servera, kadiaľ by sa jeho tabuľka dostala ku klientovi; opýtajte sa hostiteľa v sieti LAN, kadiaľ by sa dostal na rovnakú adresu. Prvé hľadanie zvyčajne ukazuje na tunel a druhé na router siete LAN, a ten rozdiel je porucha na jednom riadku. Dve hľadania sú lacnejšie ako audit firewallu a určia smer problému.

ip route get 10.8.0.37
sysctl -n net.ipv4.ip_forward

Ak hostiteľ v sieti LAN už ukazuje na server VPN, problémom je pravidlo firewallu alebo limit MTU, nie chýbajúca cesta späť. Nepridávajte trasu, aby ste opravili filter.

Otázka prvá: môžete upraviť router vzdialenej siete LAN?

Keď je router siete LAN váš, čistou odpoveďou je statická trasa do fondu VPN s adresou LAN servera VPN ako ďalším skokom. Zachováva nedotknuté zdrojové adresy klientov, čo má význam, keď hostitelia v sieti LAN logujú, filtrujú alebo obmedzujú rýchlosť podľa adresy. Takisto nevyžaduje žiadny preklad na serveri, takže tunel zostáva čistou cestou smerovania. Záväzok, ktorý vytvára, je dokumentačný, pretože fond, trasa a konfigurácia servera sa musia zhodovať.

Zlyháva ticho v deň, keď niekto fond zmení. Zapíšte hodnotu raz a berte úpravu na ktoromkoľvek z troch miest ako úpravu všetkých troch.

NAS alebo prepínač vrstvy 3, ktorý hostuje službu, potrebuje rovnakú trasu, ak neposiela všetko cez router, ktorý ju má. Skontrolujte zariadenie, ktoré ukončuje podsieti, nie len to obrátené k internetu. Malé siete majú často tri zariadenia s názorom na smerovanie.

Otázka druhá: môže sieť LAN prestať vidieť adresy klientov?

Keď router patrí niekomu inému, preklad na serveri VPN nevyžaduje spoluprácu. Hostiteľ v sieti LAN vidí adresu LAN servera, odpovie jej a server preloží späť. Preto sa zariadenia a roly vzdialeného prístupu založené na NAT správajú práve tak.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Cenou je priradenie: adresy na klienta miznú z logov siete LAN. Každý zoznam povolených na hostiteľovi v sieti LAN tak musí menovať server namiesto fondu.

Zvoľte preklad, keď spolupráca nie je dostupná, nie keď je len nepohodlná. Skrýva klienta pred každým budúcim vyšetrovaním, aj pred tými, kde potrebujete vedieť, ktorý notebook otvoril spojenie. Môže tiež rozbiť protokoly, ktoré vkladajú adresy do užitočného zaťaženia, pretože preklad žije v hlavičke. Ani jedna možnosť nie je vyspelejšia; odpovedajú na rôzne otázky o vlastníctve.

Otázka tretia: je server sám klientom iného tunela?

Predstavte si druhú topológiu: server VPN tiež vytáča komerčného poskytovateľa, takže má dva tunely a dve sady adries. Prevádzka, ktorú preposiela svojim vlastným klientom, odchádza cez poskytovateľa, a ten nebude smerovať odpovede späť na adresy fondu. Preto odpovede miznú, aj keď sú oba tunely zdravé.

Riešením je maskovať aj odchádzajúci tunel, aby poskytovateľ videl len adresu tunela servera. Opačný smer potrebuje vlastné pravidlo, pretože server, ktorý nadväzuje spojenie k svojmu vlastnému klientovi, je iný tok. Bez toho pravidla klient odpovedá na adresu, ktorú nedokáže smerovať. Umiestnite úzke pravidlo pred každé široké maskovanie, aby vyhral konkrétny preklad.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tun1 -j MASQUERADE
iptables -t nat -A POSTROUTING -d 10.8.0.0/24 -o tun0 -j SNAT --to-source 10.8.0.1

Hostitelia s viacerými rozhraniami pridávajú príbuznú poruchu, ktorá z pohľadu klienta vyzerá rovnako. Odpoveď odchádza rozhraním s nižšou metrikou, pretože zdrojová adresa bola vybraná z inej tabuľky. Skontrolujte cestu späť hľadaním, namiesto toho, aby ste predpokladali, že cesta tam ju implikuje.

Potom overte oba smery a obe veľkosti

Po zmene pingnite z klienta na hostiteľa v sieti LAN a potom z hostiteľa v sieti LAN na klienta. Druhý smer je ten, ktorý ľudia preskakujú, a je to ten, ktorý odhalí neúplné pravidlo prekladu. Zaznamenajte oba výsledky s časovou pečiatkou, aby bolo neskoršiu regresiu možné porovnať.

Potom preneste skutočné dáta, pretože malý ping, ktorý prejde, kým veľký prenos sa zasekne, je príznak MTU. Tá porucha sa objaví hneď potom, čo si zagratulujete k oprave trasy.

Nakoniec otestujte znova po reštarte. Príkazy trasy a firewallu za behu ho neprežijú a oprava, ktorá pri ďalšom štarte zmizne, bude znova diagnostikovaná niekým s menším kontextom. Urobte zmenu trvalou tak, ako to váš systém už robí, a potom raz reštartujte zámerne.