Der Kunde soll sich einfach anmelden und die route automatisch bekommen.
nicht mit pptp
du könntest zwar nach dem der pptp tunnel aufgebaut ist mit nem routing protokoll wie RIP anfangen, aber das sind alles wieder dinge die die kiste vom kunden erstmal können/haben muss
die alternative ist "böse" verbiegerei und proxy arp:
(an dieser stelle eine warnung ... sowas solltest du nur in betracht ziehen wenn du genau weißt was du tust und die entsprechende langjährige erfahrung mit gerouteten ip netzen hast ... wenn dein erster gedanke zu einem speedport-"router" führt: vergiss es)
das funktioniert nur, wenn alle maschinen die vom kunden erreicht werden sollen in einem subnet liegen, und ein benachbartes subnet in größe der zu erwartenden gleichzeitigen vpn verbindungen frei ist
du verlegst deinen pptp server in das subnetz was erreichbar werden soll ...
er bekommt in diesem subnetz eine ip, die auch gleichzeitig seine tunnel ip wird ...
hier wirds lustig: du darfst pppd neu bauen und in den sources die default netmask auf die größe des erreichbaren netzes + benachbartes vpn subnet setzen (die "netmask" option in der config ist leider ein placebo) .... wichtig ist nur, dass der client die netmask in entsprechender größe auf dem pptp link setzt
//nachtrag: natürlich musst du scriptmäsig die netmask der pptp links auf deinem server auf /32 ändern
dein pptp server muss kernelseitig für forwarding und proxyarp konfiguriert werden, zudem bekommt pptp die option proxyarp
deine server die mit vpn clients sprechen sollen bekommen alle eine neue statische route in das benachbarte subnetz der VPN clients die auf den pptp server zeigt (andernfalls kommen zwar die anfragen an, die server können aber mangels route nicht antworten)
... ab dem punkt siehst du entweder wo das ganze hinführt, oder solltest die finger von dieser "bösen" alternative lassen... sie wird zwar vermutlich funktionieren, ist aber per definition "böse" und eignet sich quasi nur als verzweiflungstat
![[HaBo]](/styles/default/logoklein.png){kind=small}
