Differences between version 14 and predecessor to the previous major change of MetaNetConfiguration.
Other diffs: Previous Revision, Previous Author, or view the Annotated Edit History
| Newer page: | version 14 | Last edited on Thursday, November 18, 2004 5:30:23 pm | by MikeBeattie | Revert |
| Older page: | version 7 | Last edited on Friday, July 2, 2004 6:55:44 pm | by AlastairPorter | Revert |
@@ -64,18 +64,46 @@
Make sure any clients on your network that you want to resolve !MetaNet addresses have the address of your nameserver as the first nameserver in /etc/resolv.conf, or their native DNS configuration. You can put your [ISP]'s nameserver after it as a precaution, if you like.
!!Firewalling
-see
FirewallNotes and PerrysFirewallingScript. Although you should be able to mostly trust other people on the metanet, you should at the very least do some basic firewalling.
+See
FirewallNotes and PerrysFirewallingScript. Although you should be able to mostly trust other people on the metanet, you should at the very least do some basic firewalling.
For example, samba/nmbd does broadcasts that will go across the metanet. You can either block traffic to and from the metanet on ports 137, 138 and 139 (both [TCP] and [UDP]) or you can add the following in smb.conf's global section:
bind interfaces only = yes
interfaces = 10.x.y.0/24
+
+__Note:__ The following is geared towards a system where the MetaNet router doesn't supply services to the MetaNet, and isn't your desktop, for example. But it can still be used and applied, with (relatively heavy) modification.
+
+The only traffic __required__ on the 192.168.0.0/16 range for your MetaNet router is BGP. So you can safely firewall off everything except port 179 tcp/udp incoming. You will need to leave outgoing open, and ports >=1024 incoming with stateful acceptance (RELATED,ESTABLISHED) since your MetaNet router will use the IP on the wan0 interface for its communication onto the MetaNet. You'll also need to allow traffic to pass back and forth between 192.168.0.0/16 and 10.x.y.z/24, but that's in your FORWARD chain.
+
+An example of this is:
+ iptables -A INPUT -p udp --dport 179 -s 192.168.0.0/16 -i wan0 -d 192.168.x.y -j ACCEPT
+ iptables -A INPUT -p tcp --dport 179 -s 192.168.0.0/16 -i wan0 -d 192.168.x.y -j ACCEPT
+ <Add extra allowances here, if your MetaNet router is serving services (like DNS, etc)...>
+ <you may also want to allow things in from your lan here (ssh!), since the following 4 rules will block them.>
+ iptables -A INPUT -p tcp --dport 1:1023 -j REJECT
+ iptables -A INPUT -p udp --dport 1:1023 -j REJECT
+ iptables -A INPUT -p tcp --dport 1024:65535 -m state --state ESTABLISHED,RELATED -j ACCEPT
+ iptables -A INPUT -p udp --dport 1024:65535 -m state --state ESTABLISHED,RELATED -j ACCEPT
+ iptables -A INPUT -p imcp -j ACCEPT
+ iptables -A OUTPUT -d 192.168.0.0/16 -o wan0 -s 192.168.x.y -j ACCEPT
+ iptables -A OUTPUT -d 10.0.0.0/8 -o wan0 -s 192.168.x.y -j ACCEPT
+ iptables -A OUTPUT -p imcp -j ACCEPT
+
+The following allows pretty much open slather access from anything on the MetaNet into your 10.x.y.z/24 segment. (change ethX to the NIC with your 10.x.y.z/24 on it):
+ iptables -A FORWARD -d 192.168.0.0/16 -o wan0 -s 10.x.y.z/24 -i ethX -j ACCEPT
+ iptables -A FORWARD -d 10.x.y.z/24 -o ethX -s 192.168.0.0/16 -i wan0 -j ACCEPT
+ iptables -A FORWARD -d 10.0.0.0/8 -o wan0 -s 10.x.y.z/24 -i ethX -j ACCEPT
+ iptables -A FORWARD -d 10.x.y.z/24 -o ethX -s 10.0.0.0/8 -i wan0 -j ACCEPT
+ iptables -A FORWARD -p imcp -j ACCEPT
+
+You'll need more than the above in your FORWARD chain if you also run something like NAT for your internet connection on your MetaNet router.
+
!!Root CA
The !MetaNet has a CertificateAuthority that it uses for signing SSL websites and potentially other cool stuff. To add this "root CA" to your browser, visit http://www.meta.net.nz/install-cert.html
Now, go to MetaNetResources to see what you can do with your new internetwork.
-----
-[1] The reason is if you use a forwarder, then all queries get forwarded to the other server and it
won't be able to resolve metanet names and addresses.
+[1] The reason is that
if you use a forwarder, then all queries for anything other than master/slave zones
get forwarded to the other server and you
won't be able to resolve metanet names and addresses.
