Before the virtual link is created R3 and R4 LSDB's look like the below.
As shown neither R3 or R4 have any record of the alternate area 0's routers, or their associated networks. To create the virtual link, with the most simple config, on R1 the below is entered, telling R1 to establish a virtual link over area 1 to router R2 using its router-id which does not have to exist in the routing table to work.
R1(config)#router ospf 1
R1(config-router)#area 1 virtual-link 18.104.22.168
Once this command is entered, a new OSPF virtual-link interface will be visible on R1, shown below.
Until a reciprocal config is applied on R2, to establish its end of the virtual-link the following messages will appear. '%OSPF-4-ERRRCV: Received invalid packet: mismatched area ID, from backbone area must be virtual-link but not found from 10.0.15.1, FastEthernet0/0', And once R2 is configured an adjacency message will be logged. '%OSPF-5-ADJCHG: Process 1, Nbr 22.214.171.124 on OSPF_VL2 from LOADING to FULL, Loading Done'. This can be seen in the OSPF neighbor table, noting since the virtual-link is point-to-point there is no DR/BDR.
Now that the virtual-link is established, R1 and R2 will flood their LSDBs to each other and as a result, both R3 and R4 will end up having entries in their LSDB for the other part of area 0.
Notice the (DNA), DoNotAge flag, this is set in the LSA when a virtual-link is used causing the LSA not to age out, to prevent excessive flooding of the virtual-link. Looking deeper at the Type 1 LSA for router R4 in the R3 LSDB, we can see the entry for 192.168.4.1, and also the DNA flag being mentioned again.
Finally on R3 the route to the 192.168.4.1 network can be seen in the IP routing table, and a successful traceroute sourced from R3's loopback interface.