Thanks a lot for your deeply and clearly explanations ;-) Based on your analysise for my case, I've tried the following method so that I can let the nntp to use the original default routes and it does the trick:
route add -host news.rusnet.ru gw 192.168.0.1 As for other methods you mentioned in the previous thread, I'll try them one-by-one ;-) Thanks again. Regards 2015-04-03 19:38 GMT+08:00 Duncan <1i5t5.dun...@cox.net>: > Hongyi Zhao posted on Fri, 03 Apr 2015 16:23:33 +0800 as excerpted: > > > Are there any workarounds for this case if I want to use Pan2 under vpn > > environments? > > I had a reply mostly composed earlier, but then decided I didn't know > enough about your intent and was making too many unwarranted assumptions > in the post as it was written, so I killed it without sending. This time > I'll use two questions and explain the results of both answers, for both, > avoiding that problem. > > > I should however mention that I don't claim to be a routing expert and > have basically no experience at all with VPNs. Tho I know a reasonable > amount about IPv4 basics including routing in general, see that you are > on debian and can read the route manpage. So this should at least help > to point you in the right direction, tho I can't guarantee all the > details are exactly correct. This is exactly where I'd be starting were > I in this situation, except that /were/ I in this situation, I'd probably > already know more about VPNs as I'd have at least setup the VPN, already, > something I haven't at this point actually ever done. So you're ahead of > me in that aspect. =:^) > > > OK, so the route table you posted earlier was this: > > > werner@debian:~$ ip route > > 0.0.0.0/1 via 10.211.38.206 dev tun0 > > default via 192.168.0.1 dev eth0 proto static > > 10.211.38.206 dev tun0 proto kernel scope link src 10.211.38.205 > > 58.19.210.249 via 192.168.0.1 dev eth0 > > 128.0.0.0/1 via 10.211.38.206 dev tun0 > > 192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.3 > > > The two link-scope routes are: > > 192.168.0.0/24 dev eth0 src 192.168.0.3 > 10.211.38.206 dev tun0 src 10.211.38.205 > > The 192. route is your ethernet/LAN route, standard 192.168.0/24 (256 IP > subnet), with the .3 address being the assigned local machine ethernet IP > address. > > The 10. route is the point-to-point established over the VPN, .205 being > the local machine tun0 address, .206 being the remote address. The lack > of a mask means it's point-to-point, the equivalent of a /32 or > 255.255.255.255. Only packets to .206 specifically, get routed that way. > > > The other two routes on the raw ethernet 192.168.0/24 subnet are: > > default via 192.168.0.1 dev eth0 > 58.19.210.249 via 192.168.0.1 dev eth0 > > 192.168.0.1 is obviously the local gateway, likely your router. > > The first route is the default route, taking anything not specifically > routed elsewhere. This would be your normal internet route. > > The 58. route is point-to-point. Based on your VPN config, 58.19.210.249 > is the VPN-external remote host IP of your VPN, the machine to which you > connect to establish the VPN. > > > That leaves the other two routes on tun0, the VPN itself. > > 0.0.0.0/1 via 10.211.38.206 dev tun0 > 128.0.0.0/1 via 10.211.38.206 dev tun0 > > The .206 address is the VPN-internal remote host on the VPN, with these > routes using it as their gateway. > > The one-bit bitmask indicates that the network each of these routes is > half the IPv4 address space, with 0.0.0.0 being the first address of the > bottom half, while 128.0.0.0 is the first address of the upper half. > Combined, therefore, these have the effect of overwriting the default > route, so nothing that would have fallen back to it routes to it, as it > is instead routed via one of these routes thru the VPN to the > gateway .206 machine at the other end. > > These two routes, then, are what is causing everything to route thru the > VPN. > > > The big question is then, is this what you intended, use this VPN for all > your not otherwise specifically routed access to the net, or not, all not > otherwise routed traffic you still want using the default route? > > In your original post, you said the problem occurs when you are using a > VPN method to access the internet. That implies that you INTEND to route > over the VPN everything not otherwise specifically routed, in which case > the above routes are correct. > > If, however, you only want specific traffic routed over the VPN, with > anything not specifically routed over it, routed over the previous > default route instead, then those two routes are wrong and should be > deleted, with a more specific replacement route for just what you intend > to route to the VPN, created instead. > > As I said I'm no expert, but for this second case, based on the logged > route commands you posted and the route manpage, and assuming you want to > route only traffic for the 10/24 network (mask 255.255.255.0) to the VPN, > I can guess the route delete and add commands might look like this: > > route del -net 0.0.0.0 > route del -net 128.0.0.0 > route add -net 10.211.38.0 netmask 255.255.255.0 gw 10.211.38.206 > > Of course you'd adjust that netmask as appropriate for the vpn. > If it were the entire 10/8, you'd use a netmask of 255.0.0.0. > > > Back to the (almost) everything-over-the-vpn case, since that's what your > first post implied you wanted and I've not covered it yet. In that case, > there's another question, what about the nntp connection? Did you want > it over the vpn as well, or did you want it bypassing the vpn, direct on > the ethernet connection? > > If you wanted it over the VPN, then your vpn must be setup to allow nntp > traffic, something that's apparently not the case now. You'd have to > contact the people who provide you the vpn connection service and ask > them to enable it, out of scope for a post such as this. > > If however you want nntp to bypass the vpn despite all your other traffic > not otherwise routed being routed thru it, then you need to setup a > specific exception route direct over the 192. ethernet connection. > Again, while I don't claim to be an expert, based on the information > available, the command for that might look something like this. > > route add -host news.rusnet.ru gw 192.168.0.1 > > Of course, with this option the nntp connection will be in-the-clear > direct over the normal ethernet connection, NOT over the encrypted VPN. > If that's what you intend, as may well be the case if only supposed to be > an employment related vpn or the like, great, but if for instance you're > attempting to use the VPN to avoid local ISP level censorship or tracking > of your nntp connection, you really must talk to the vpn service provider > and arrange for them to allow it, instead, because this option won't > cover it. > > -- > Duncan - List replies preferred. No HTML msgs. > "Every nonfree program has a lord, a master -- > and if you use the program, he is your master." Richard Stallman > > > _______________________________________________ > Pan-users mailing list > Pan-users@nongnu.org > https://lists.nongnu.org/mailman/listinfo/pan-users > -- Hongyi Zhao <hongyi.z...@gmail.com> Xinjiang Technical Institute of Physics and Chemistry Chinese Academy of Sciences GnuPG DSA: 0xD108493
_______________________________________________ Pan-users mailing list Pan-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-users
