Ale já jsem přece nikdy netvrdil, že vám to nebude fungovat. Na světě určitě existuje spousta lidí, kteří se dokáží poškrábat levou nohou za pravým uchem a připadá jim to jako skvělý nápad. Klidně se plácejte po rameni, jak jste to vymyslel, ale to budete dělat jen do chvíle, kdy se to začne chovat nepředvídatelně, nebo kdy k tomu přijdete po 5 letech (vy, nebo nedejbože někdo jiný) a budete se divit, proč to funguje tak divně napůl a ne tak, jak by člověk z logiky věci předpokládal. Ne nadarmo máme nějaké best practices, aby se věci dělay tak, jak mají, místo aby se bastlily.
Ale radíte někomu, kdo si ve volném čase hraje a zkouší něco nového. Nejste ve firmě, kde to musí běžet na první našlápnutí bez chyby. Já když něco zkouším, mám obrovskou radost, když to začne fungovat a pak na to vymýšlím best practice. Sice jste tu perfektně popsal rozdíl mezi TUN/TAP a dal příklady na ipsec a shorewall, ale jaksi mu to moc nepomohlo. Já dám příklad na iptables a openvpn.
Takže na serveru musí být toto:
dle best-praktice
push "route $rozsah_lan_serveru maska"
- to řeší přístup na reálnou IP serveru. Na klientu pak bude v konfigu
pull
Na server ještě možná
topology subnet
, ale mě to funguje i na default
Pak na serveru v iptables (záleží na výchozích politikách) povolit nejlépe vše (INPUT z eth a tun, OUTPUT, FORWARD tun a eth) to není dle best practices, ale důležité je to rozběhat. Ideálně dát pravidla jako první. To je na serveru vše, tak to mám já a přistupuju i do LAN za serverem.
Na klientu je potřeba jen v konfigu pull (viz výše), v iptables jen nat, tam máte politiky na accept
iptables -t nat -A POSTROUTING -o $VPN -j MASQUERADE
Pokud toto nebude fungovat budeme hledat dál. Tohle řeší jak přístup na server pod LAN adresou, tak směrování na obou stranách.
No a nebo se na to vyprdněte, přejděte na ipsec a shorewall, nebo si najměte odborníka, který "tomu rozumí". Je to tak správně?