Might be a bug on packet tracer. Although daisy-chaining virtual-links is not the best of options, it creates a contiguous area 0 tunnel.
I've gone through your packet tracer file, and in fact, when the ospf process is reloaded, sometimes, 30.0.0.1 will be considered an ABR for the OSPF process (under the show ip ospf border-routers output), that is where the route will be installed on the RIB, however, on both broken and working state scenarios, the required LSA type 1 for area 0 with the ABR information will be there, it will just not install it... (in addition to that, the clear ip ospf process command is also bogus on Packet Tracer, it doesn't cleanup the border-routers information every time).
To avoid going way to far on explanation, lets keep it simple:
* The 20.0.0.0/24 route, being a summary route (LSA3), will resolve its next hop by it using its closest ABR based on the OSPF Database information.
Who is the ABR originating this route?, it can be either 30.0.0.1 or 20.0.0.1. Based on the OSPF table information, 30.0.0.1 is the closest, however, the OSPF process, sometimes, it doesn't consider it an ABR.
Router#show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route
Gateway of last resort is not set
10.0.0.0/24 is subnetted, 1 subnets
O 10.0.0.0/24 [110/4] via 40.0.0.1, 00:19:00, GigabitEthernet0/0
20.0.0.0/24 is subnetted, 1 subnets
O IA 20.0.0.0/24 [110/3] via 40.0.0.1, 00:00:10, GigabitEthernet0/0
30.0.0.0/24 is subnetted, 1 subnets
O IA 30.0.0.0/24 [110/2] via 40.0.0.1, 00:19:00, GigabitEthernet0/0
40.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 40.0.0.0/24 is directly connected, GigabitEthernet0/0
L 40.0.0.2/32 is directly connected, GigabitEthernet0/0
50.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 50.0.0.0/24 is directly connected, GigabitEthernet0/1
L 50.0.0.1/32 is directly connected, GigabitEthernet0/1
Router#show ip ospf border-routers
OSPF Process 1 internal Routing Table
Codes: i - Intra-area route, I - Inter-area route
i 40.0.0.1 [2] via 40.0.0.1, GigabitEthernet0/0, ABR, Area 0, SPF 2
i 60.0.0.1 [2] via 50.0.0.2, GigabitEthernet0/1, ABR, Area 0, SPF 2
i 30.0.0.1 [3] via 40.0.0.1, GigabitEthernet0/0, ABR, Area 0, SPF 3 ----- It is considered a border router.
i 20.0.0.1 [4] via 40.0.0.1, GigabitEthernet0/0, ABR, Area 0, SPF 4
i 40.0.0.1 [1] via 40.0.0.1, GigabitEthernet0/0, ABR, Area 3, SPF 1
i 60.0.0.1 [1] via 50.0.0.2, GigabitEthernet0/1, ABR, Area 4, SPF 1
When the route is not displayed, it is because the 30.0.0.1 is not considered ABR.
But for what reason it could not be considered an ABR? All it needs it is an LSA type 1 from Area 0 (where the tunnel is daisy chained) with the ABR flag on it:
(from #show ip ospf data router)
LS age: 1555
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 30.0.0.1 ------------- 30.0.0.1 LSA Type 1
Advertising Router: 30.0.0.1
LS Seq Number: 80000003
Checksum: 0x7a12
Length: 48
Area Border Router ----------------- It is an ABR
Number of Links: 2
Link connected to: a Virtual Link
(Link ID) Neighboring Router ID: 20.0.0.1
(Link Data) Router Interface address: 20.0.0.2
Number of TOS metrics: 0
TOS 0 Metrics: 1
Link connected to: a Virtual Link
(Link ID) Neighboring Router ID: 40.0.0.1
(Link Data) Router Interface address: 30.0.0.1
Number of TOS metrics: 0
TOS 0 Metrics: 1
The difficult part is that, in both broken and workin state, the database entry is always there, with the ABR flag, so I'm suspecting an issue with packet tracer processing that ABR status from time to time.
I would suggest to try reproducing this scenario on GNS3, Eve-ng or VIRL instead of PT because of its bugs and limitations.
