jchudoba tam ještě jeden rozdíl v konfiguraci v závislosti na (ne)přítomnosti Terminátoru, a to že se to (ne)vytáčí nad VLAN848.
Pravda, na to jsem zapomněl.
Nicméně...asi jsem to zakřikl 😂. Dnes v 12:35 se to stalo opět. Zkusil jsem, co psal @iTomB:
iTomB Pripadne muzes zkusit zakazat port na tom RB800 eth3. Pak by zmenu pocitil terminator a ne mikrotik.
Přesně toto jsem udělal, PPPoE tunel ale ještě minutu visel running, protože mám nastaveno "Keepalive Timeout = 60" (už ani nevím proč). Když jsem předtím dal disable na hlavním RB, tak PPPoE spadlo hned (asi závislost na fyzickém portu).
Až tunel zdechnul, tak jsem eth3 na RB800 zpět povolil a tunel se navázal a to funkčně. Takže takto to lze "resuscitovat taky".
Nicméně jsem pořídil ten sniff "vadné" komunikace. Bohužel jsem tak nestihl ten "přelom" z funkční do vadné, jak psal liquidcz .
Po celou dobu, co jsem dělal sniff mi běžel z NTB ping na 1.1.1.1 (samozřejmě bez odpovědí). .PCAP je dostupný zde. Tentokrát jsem sniff udělal nad ETH3, nikoli nad ETH2, což bylo na obrázcích výše (pouze kvůli jednoduššímu RX/TX "dovozování")....
Ještě bych chtěl osvětlit pár věcí, které jsou v tom sniffu vidět a předejít tak nějakým "zbytečným pochybám":
Lze tam vidět, že přes PPPoE tečou i nějaká data na lokální 192.168.0.0/16 adresy. Ty by tam správně neměly co dělat. Je to dáno tím, že tyto některé adresy (namátkou 192.168.3.10) jsou za VPN tunelem, který ale spadnul, takže se "znefunkčněla" i routa, která tento provoz posílá do L2TP tunelu XY. Takže paket vyhověl až defaultní routě 0.0.0.0/0, která vede do PPPoE. Proto tam takovýto nějaký provoz je.
Sice bych to možná měl mít nějak ošetřené, aby se tam ty pakety vůbec nedostaly, ale co už 😁
Edit: jenom doplním, že ten sniff běžel jenom krátce, přišli mi zbytečné nechat to běžet třeba minutu. Proto tam ty pingy na 1.1.1.1 jsou asi jenom 3 - (trvaly déle, protože spadly do timeoutu)
