ipip туннель на pppoe

Кажися я догоняю почему не взлетает с другой стороны.

Сторон А
enp37s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
ipip-filial@enp37s0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1480

Сторона Б
enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 <- через что поднят PPPoE
ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492
ipip-office@enp1s0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1480

PPPoE 8 байтов отъедает от MTU. Получается надо в туннеле уменьшить максимальный размер пакета?

https://ru.stackoverflow.com/a/475791 Не проверял

Чё-т это не совсем то.

Может я на стороне Б не так организовал туннель? Я интерфейс ipip привязал к физическому enp1s0, на котором поднимается ppp0, но IP адрес от провайдера назначается на ppp0 интерфейсе. Мне кажется, что каким-то макаром надо ipip привязать к ppp0, но как это сделать в systemd-networkd? Он же виртуальный и поднимается уже опосля?

На всякий случай как сейчас есть на стороне Б

cat /etc/systemd/network/ipip-office.netdev
[NetDev]
Name=ipip-office
Kind=ipip
MTUBytes=1450

[Tunnel]
Remote=там
Local=тут
TTL=64

cat /etc/systemd/network/ipip-office.network 
[Match]
Name=ipip-office

[Network]
Address=192.168.200.1/31

cat /etc/systemd/network/enp1s0.network 
[Match]
Name = enp1s0

[Network]
DHCP = ipv4
Tunnel=ipip-office

ip a
1: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether e8:ff:1e:dc:ad:e2 brd ff:ff:ff:ff:ff:ff
    altname enxe8ff1edcade2
    inet6 fe80::eaff:1eff:fedc:ade2/64 scope link proto kernel_ll 
       valid_lft forever preferred_lft forever
2: tunl0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000
    link/ipip 0.0.0.0 brd 0.0.0.0
3: ipip-office@enp1s0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1450 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ipip внешнийIP peer внешнийIP-стороныА
    inet 192.168.200.1/31 scope global ipip-vdk
       valid_lft forever preferred_lft forever
4: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc fq_codel state UNKNOWN group default qlen 3
    link/ppp 
    inet внешнийIP peer 172.16.30.1/32 scope global ppp0
       valid_lft forever preferred_lft forever

Привет, по диагонали посмотрю, но не обещаю. Ссылку скидывал из соображений, что скорее всего vpn это network требующая маршрутизации: ovpn в этом плане userfrendly, поэтому ее полусознательно везде «заталкивают». https://wiki.gentoo.org/wiki/Handbook:Parts/Full/Networking/ru#.D0.A2.D1.83.D0.BD.D0.BD.D0.B5.D0.BB.D0.B8.D1.80.D0.BE.D0.B2.D0.B0.D0.BD.D0.B8.D0.B5 В целом, ipsec это семейство/стек и в года два назад ipsec-tools был deprecated и под удаление в репах шёл: могу ошибаться, но в т.ч. по этой же причине пошёл «бум» на «ядрёные»-vpn

https://blindage.org/en_US/administration/tunnel-ipip-mezhdu-linux По части MTU, не помогло?

Проблему решил внимательным чтением того, что выдавал гугл.
Набросал (взял готовый из интернетов Ваших) скрипт типа

LOCAL_IF = интерфейс (ppp0)
LOCAL_IP = локальный IP PPPoE
REMOTE_IP = Внешний IP другого конца туннеля

ip tunnel add ipip-office mode ipip local $LOCAL_IP remote $REMOTE_IP dev $LOCAL_IF ttl=64
ip addr add 192.168.200.1/31 dev ipip-office
ip link set ipip-office mtu 1472 # Стандарт MTU у IPIP = 1480. Тут мы уменьшаем размер из-за PPPoE, служебные данные которого занимают 8 байт от 1500
ip link set ipip-office up

Помещаем скрипт в /etc/ppp/ip-up.d/ipip-office

ВСЁ…!!!

Может кому пригодится и спасибо откликнувшимся.

p.s> Когда пошли пинги по внутреннему IP-адресу, мои восторженные и щенячьи визги были слышны на соседней улице, но не долго, потому как по туннелю мог пройти только пинг и больше ничего. Как оказалось необходимо было ещё познакомиться с MSS (MTU и MSS - разные вещи). В общем для полноты картины в таблицу mangle файерволла надо добавить следующее

table ip mangle {
	chain FORWARD {
		type filter hook forward priority mangle; policy accept;
		oifname "ppp0" tcp flags & (syn | rst) == syn tcp option maxseg size 1400-65495 counter tcp option maxseg size set rt mtu
	}

p.p.s> Это кстати один из провайдеров г. Омска. Надеюсь больше ни где не встречу такого…=)

А как ты понял что проблема была в MTU, если у тебя в ICMP payload всего 64b ?

А как ты понял что проблема была в MTU, если у тебя в ICMP payload всего 64b ?

по туннелю мог пройти только пинг и больше ничего.

Наверно потому, что при открытии браузера и попытке зайти на любой сайт, ничего не происходило.

А, не дочитал - просто в первом посте у тебя и пинг не ходил.

Молодчина!)