Re: on to letsencrypt

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Tim:
>> Does your computer actually recognise one of its WAN ports as being
>> that IP?    (108.220.213.121)

Jack Craig:
> Apparently not 
> 
> I can do a telnet connect to IP for port 53 from 10.0.0.1 & localhost
> 
> 10.0.0.101 and the external IP do not connect
> 
> As my external IP is being supported by port mapping by router, all
> port 53 connects are routed to the internal address of 10.0.0.101:53.

Okay, as Ed's said, 108.220.213.121 isn't an address of your computer,
it's assigned to your public facing side of your first router.  So,
BIND cannot listen on it.  I'd go along with Ed's example:

Run a named server that listens to all interfaces, and allows queries
from any address.  Likewise with the webserver.

If you were doing something tricky with your webserver, it not actually
having that public IP might be an issue, too.  Things can get in a
confused circle if they try to resolve an IP to a name, that name back to an IP, and it's different.



>> But the supplied named.conf hasn't defined a "wan-view" acl, you've
>> only done "internals" and "slaves".

> Given these ACL's not employed  and questionable listen commands how
> should I properly have configured this interface to provide external
> IP processing for primary dns service? 

For the time being, let your named server answer all queries for your
domain name with the public addresses.  See if it, then, works as
expected.

Once you've dealt with that, you can consider whether you really want
to do split DNS (answering outside queries with your public IPs, and
internal queries with your internal IPs), or whether you let your
register handle all outside queries (I would), or whether you use
different domain names for inside and outside (that's my approach in my
network).

Since you only appear to have one real interface, it's going to be
harder to configure BIND to distinguish between what's inside and
outside.  After all, the external queries are going to come from a
local address (your router), you're probably going to have use the
router's specific internal address as the definition for outside
queries.

If you only have one PC, as you've previously outlined, running BIND is
serious overkill.  You can do all you need with the /etc/hosts file.

ACLs have some predefined terms:

 "any" matches any and every IP address,

 "localhost" matches any IP used by the computer it's running on,

 "localnets" matches any IP on any network the computer is on,

 "none" matches nothing.

When those definitions are not useful enough, you start using actual IP
addresses or IP ranges (e.g. 192.168.0.0./24 is the entire range
192.168.0.0 through to 192.168.0.255).

Try Ed's sample named.conf.  Then if you really want to try doing split
DNS, I think you'll have to go down this route, using rules something
like these *within* the config file:

	listen-on port 53 { any; };

	listen-on-v6 port 53 { any;};

	allow-queries { any; };

	acl wan { type in the internal IP of your router your PC is directly plugged into; };

	acl lan { 127.0.0.1; };

	view wan {
		match-clients { wan; };
		zone "wan-linuxlighthouse" {
			type master;
			file "wan-linuxlighthouse.zone";
		};
	};


	view lan {
		match-clients { lan; };
		zone "lan-linuxlighthouse" {
			type master;
			file "lan-linuxlighthouse.zone";
		};
	}

With the associated wan- and lan- zone files only containing IPs
applicable to themselves (the wan zone only has public addresses, the
lan zone only has local addresses).

Match the special outside rule first, then fall back to the internal
rules.

NB:  While the defaults for various options are often any/all if you
haven't set any contradicting rules, I don't know if alternative
defaults have been complied in for Fedora's BIND.  So I play safe and
define the things explicitly.

> visible interfaces 
> 
>  ip a
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
> group default qlen 1000
>     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>     inet 127.0.0.1/8 scope host lo
>        valid_lft forever preferred_lft forever
>     inet6 ::1/128 scope host 
>        valid_lft forever preferred_lft forever

That's your localhost with IPv4 and IPv6 addresses.  Localhost is how
the computer refers to itself.  It's like you looking in the mirror and
thinking "me."

> 2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel
> state UP group default qlen 1000
>     link/ether 50:65:f3:4a:ec:e5 brd ff:ff:ff:ff:ff:ff
>     altname enp0s31f6
>     inet 10.0.0.101/24 brd 10.0.0.255 scope global noprefixroute eno1
>        valid_lft forever preferred_lft forever
>     inet6 fe80::15ef:5535:377f:e73f/64 scope link noprefixroute 
>        valid_lft forever preferred_lft forever

That's your ethernet interface within your network, between your
computer and routers, and any other devices.


> 3: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
> state DOWN group default qlen 1000
>     link/ether 52:54:00:4f:91:99 brd ff:ff:ff:ff:ff:ff
>     inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
>        valid_lft forever preferred_lft forever
> 4: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel master
> virbr0 state DOWN group default qlen 1000
>     link/ether 52:54:00:4f:91:99 brd ff:ff:ff:ff:ff:ff

These are virtual bridges, which you don't appear to be using (a bridge
between real interfaces, as in the prior paragraph, and emulated ones
used by virtual installations).  For what it's worth, my computer had
the same kind of thing set up by default.  But since I don't use
virtual computers on my hardware, I removed them.

>From what I can gather of this tangled thread is that your network is
something like:

ISP --- router --- another router --- your computer

Each router will have a different IP address at their inside and
outside interfaces (that diagram has outside WAN on the left, inside
LAN on the right).

Your ISP allocates you a bunch of IPs.  You either need to configure
your router to be all of those IPs and route them through to where you
want (doing some complex NAT).  Or configure you router to be one of
those IPs, and route the others through to where you want, and
configure the destination(s) to be the other IPs (configuring your
routers as gateways).  Domestic routers may not be configurable enough.

-- 
 
uname -rsvp
Linux 3.10.0-1160.24.1.el7.x86_64 #1 SMP Thu Apr 8 19:51:47 UTC 2021 x86_64
 
Boilerplate:  All unexpected mail to my mailbox is automatically deleted.
I will only get to see the messages that are posted to the mailing list.
 
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure



[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux