/ 28 and secondary / 25 ip address blocks were defined by the ISP on our line. However, when I want to distribute pppoe over the / 25 ip address block, access to ip addresses from inside and outside cannot be provided. The problem is solved when I define the ip address I give to the customer on the router, activate it and make it passive again. I’m waiting for your help.
If the ISP doesn’t route the /25 block using one of the /28 addresses as a gateway but sends an ARP requests for the address from the /25 block, which seems to be the case from your description of the behaviour, setting arp=proxy-arp on the WAN interface will make your 'Tik respond to these ARP requests with the WAN interface’s own MAC address, making the ISP gear send the IP packets for this address to the 'Tik, which will then forward them to the PPPoE client actually bearing that address. But it will do so for IP addresses from all connected subnets, so if this bothers you, you’ll need to add an /interface bridge, move the IP configuration from the etherX used as WAN to the bridge interface (and set arp=proxy-arp on the bridge as it is an IP related setting), make etherX a (single) member port of that bridge, and use bridge filter rules to accept only ARP requests asking for IP addresses from the two public subnets and drop all the other ones.
The same is doable with arp=enabled (the default) on the bridge interface, and a bridge nat rule: chain=input in-bridge=br-wan mac-protocol=arp arp-dst-address=y.y.y.y/25 action=arp-reply
The correct solution is to talk with ISP and come up with with different config where /25 is routed to you as whole. If you get that many addresses, you’re not just some unimportant residential customer and they should want to make you happy. And it’s not like routing subnet to you would be any difficult, it’s the simplest thing.
If it can’t be done for some reason, then proxy ARP must work too. If it doesn’t, it can be e.g. some firewall problem or other misconfiguration.
If it is difficult to talk with the ISP, the other possibility is not to say “neither of the suggested solutions worked” but to post the complete configuration which didn’t work for analysis. Both suggestions do work if the actual situation on the uplink is what we expect - already your original post wasn’t really clear about that, but from the description of the behaviour it seemed to be the case.
Sniffing on the WAN interface also helps debug the configuration.