From my TCP/IP dash:
1) I need to investigate # how I can get 2 computers to directly interact with each other, and the degree to which WAMP is already a [web]-server. I don:t want people to have to own a domain, as that defeats the purpose of private web. I want 2 people to be able to directly make requests, if someone else:s IP address is known. <br> 2) Secondly, within this architecture, how do people with the same IP address talk to each other, because they will be on different computers? Does the computer also have an ID? What if I want to retrieve data from my friend:s computer, but his dad is also on his own computer, in the same IP-address? <br> 3) Of course it must be possible # to connect directly to someone:s computer, without them needing to have a website. We do a) Skype calls b) Teamviewer, but in some cases, this routes through another server, 3rd party. Nevertheless, even that server, and even if it does have a domain, is able to connect to you, so if we remove 1 out of the 3 parties, we would have our 2 party desired setup. <br> 4) A domain is an address; an IP is also an address. A domain is just a name, for an IP address. Your computer also has a unique address, that is not your IP address. It is possible to Skype call your computer, without Skype calling another computer, on the same connection; you need that person:s Skype username, and that person, by virtue of having a connection to Skype:s server, also reveals their IP address, to Skype.
H3S1: TCP-conn is characterized by internal.network-comms:
<WP.MIC-H2S70, H3S4.H4S1 case study: Corporate private networks x productivity>: <Wang pg-8> WebSocket provides TCP-style networking for HTML5 applications without wrecking browser security and it has a modern API. Hu: Historically, extra.network-comms between a server and a remote | client has been handled exclusively by HTTP-requests, but in order to enable LAN-networking, as well as server-server extra.network-comms, one has to embrace TCP. HTML-5, historically, has not supported such connections, through its own interface<WP.MIC-H2S55,H3S3>, but that doesn’t mean we want to lose the convenience of employing web-browsers, even when their interface actions trigger TCP-requests. As posited by <Wang, 20s, a-r>, WebSockets poses a sort of pilot study, to the keepers of HTML at Google et al, that TCP, in-general, should be served by HTML-5 and by proxy, web-browsers. However, without adequate–support in HTML-6, and beyond, we will be forced to, once again, funnel a disproportionate proportion of interactions through this WebSockets port, restarting the viscous cycle of squeeze-holing. Why can’t protocol-updates be prophylactical?
H4S1: How private web computers will identify each other:
On private web: even if you inform of your IP, you might switch to a different IP address, which would render the whitelist obsolete, unless it just asks you to do it again, because their IP is still saved.
H4S2: How private web computers will connect with each other:
H3S2: How to host a website on your computer:
Hu: The result should be an address, that people can request-from, across an IP-network # which has the ability to serve files and data, as well as receive data, from other users.
H3S3: How to host a website with an IP-address, domain-less:
Hu: My website should be accessible, if you simply type in my IP-address, such that I don’t need to own, and maintain, a domain name, through the central | registrar, and I can use the IP-address, that is already included, in my modem–package.
H4S1: How to close access to the IP-address, but from a white-list:
H4S2: How to limit file | access to a specific | directory, on my computer:
Q: If I host a website with WAMP, which is a powerful | technology, can I limit access to my www-folder? How do I know this is working, for sure?
Post: We can potentially hack around this, by first following a tutorial with a domain name, then attempting to remove it, revealing only our IP-address.
H4S3: How to link up an ip-address and file directory path to open a desired.web-page<theory>:
<WP.MIC-H2S122,H3S2.H4S3>Torogi Pro<10:51><blob><fbno>demonstrates in a short video the possibility of serving a web-page with his home IP address: 184.108.40.206; entering this IP-address from a third.party-device opens up a desired web-page, the home-page of a website called UN-APP. We know from his descriptive | video that the files for this site are served from his computer, and as with any other<here-Turing><fbno>, we know there must be other files on his computer, so there must have been a process of pointing the IP-address to a particular | directory<Turing-3>Subsequent to<10:51>he associates this IP-address with a domain name, but the site was already previously | accessible.
At<9:30>, he demonstrates a different result: accessing the same | site via IP from the device that launched it: Torogi: “my | computer is going outside the internet, coming back, accessing what I’m hosting“
At<9:15><anthro>, Torogi states that 220.127.116.11 is his public | IP address, as determined by his ISP |=full router<Turing>. In contrast, 192.168.1.10 is what he states is his private | IP address, which was the former | method for accessing the same UN-APP home-page, but this is restricted to local | access, to that device. [D], at the bottom left, 9:04, the file | path, for this page.
Hu: There must be a redirect of the IP-address to the file containing the home | page, or and to a # folder | path containing the files to that website in general, and this is the purpose of the www-folder in WAMP, so most likely, the redirect is being handled by an AMP<Turing>, in Torogi’s case, XAMPP, a recursive | acronym for XAMPP Apache + MariaDB + PHP + Perl<Wikipedia, a-r>. Even more specifically, within WAMP, we know from our research<H2S129>that it’s:
⭐ The presence of Apache in your computer can handle the redirection of your public.IP-address to a specified file path on your computer, or, a “web-site”.
Moreover, it’s quite likely # that the specification for this redirection occurs in C:\wamp64\bin\apache\apache2.4.51\conf\extra\httpd-vhosts.conf or a sister | file.
H5S1:<Torogi, :40>The PC where we are going to install the web server, which will run our web app. Hu: Torogi confirms that the web app will be run on a web server, such as WAMP.<2:51>Hu: Torogi highlights Apache Web Server<world-salad><anthro>.
Hu: Typing in my own private IP address in browser, http://192.168.1.223/, displays the WAMP | localhost homepage.
H5S2: Identifying the directory | path to the project | folder: http://192.168.1.223/flare/, and to a file: http://192.168.1.223/flare/client-display.php; identifying the IP-path to the WAMP.www-folder suffices, and the rest, controlled by WAMP’s internal folder–hierarchy<Turing>
H5S3: C:\wamp64\bin\apache\apache2.4.51\conf\extra\httpd-vhosts.conf: below is a sample of a Virtual.host-entry; changing the ServerName here, also changes the server-name that is displayed in the “Your VirtualHost” section on the WAMP-home<port-manager>. This means that http://localhost/add_vhost.php directly | edits this | file. When the ServerName is changed from this file and saved, the error: The ServerName cess is not defined into hosts file: is returned in the “Your VirtualHost” section, whereas # when the folder | name is changed in explorer, this different error: The path c:/wamp64/www/chess for DocumentRoot does not exist (File c:/wamp64/bin/apache/apache2.4.51/conf/extra/httpd-vhosts.conf): and the error: The path c:/wamp64/www/chess/ for <Directory … does not exist (File c:/wamp64/bin/apache/apache2.4.51/conf/extra/httpd-vhosts.conf). This indicates that both are being checked against each other, but there may be a tertiary file, that defines, and is checked against #
<VirtualHost *:80> ServerName chess DocumentRoot "c:/wamp64/www/chess" <Directory "c:/wamp64/www/chess/"> Options +Indexes +Includes +FollowSymLinks +MultiViews AllowOverride All Require local </Directory> </VirtualHost>
25. Bh3 Qxh3 26. Rxe8+ Rxe8 27. Qxf7+ Kh7 28. Qxe8 Bxg3 29. Qe4+! Kg8 30. hxg3 Qxg3+ 31. Qg2! Qxd3 32. Qd5+ Kh7 33. Bxd4 5.7 https://lichess.org/7OaUiwCO/white#48<WP.MIC-H2S114,H3S2.H4S2>
H5S4: Setting private IP as static:
<Torogi 5:11>: from Control Panel\Network and Internet\Network Connections->Status->Details [L] to Control Panel\Network and Internet\Network Connections->Properties->Internet Protocol Version 4 (TCP/IPv4)->Use the following IP address: [R], he manually inputs the displayed figures copy | paste.
H5S5: Accessing router | configuration: Torogi uses the IP associated in [D, L, above] as IPv4 Default Gateway to access his router | login. I was able to replicate this result, on my home | computer. Using a password that is publicly displayed on my router, as in, the phyiscal device in my TV-cabinet, I was able to login to an internal | dash. H6S1: Hu:<Turing>In my router | settings, I am able to see a list of devices connected to the router, as well as the assigned | private IP. This can be leveraged, later, to configure intra.network–file,access; by default, attempting to access one of the IPs returns a ERR_CONNECTION_TIMED_OUT, by default. H6S2: When a search of What’s my IP is used on Google, the returned is not these private | addresses, it’s the public | address H6S3: Default asymmetrical IP-blindness<ch-42>: by default, external sites cannot determine your private | IP-address, and within WAMP, you may not be able to # redirect access to public to private<50% 12/5/22><fbno>, although this is not fundamentally | correct. Nevertheless, this is the primary | purpose of your router, to resolve this asymmetrical–blindness<Turing> #
H3S4: The UX of cli-ser-ser-cli architecture:
Hu: In cli-ser-ser-cli peer-to-peer<Turing>, I will only ever be connected to my | own | server<Turing-nasty!><fbno>; I will not be accessing your | web-pages, for communications. // add ref to Britannica: Alexander Graham Bell, and seek push to MIC #
H4S1: Implementation for communications:
Hu: For communications, I am only connected to my server, and our servers will transfer data, back and forth. Therefore, my server needs to specify the IP-address of your server, by drawing from a list of my connected users, in the users-tb, of my db.
H4S2: Implementation for HTTP-browsing<Turing>
Hu: HTTP-browsing will be analogous to linking off, from pages served by my server, through p-dash, only, to an external | site, some of which are public | sites, like YouTube, some of which are web-pages, hosted by unlisted–friends; in the latter | scenario, those pages will be served up directly, from your server, and your database, so my HTTP-request, in that case, will go directly to your machine.
H3S5: Router.Firewall-settings lit-rev:
Hu: One’s router<H3S3.H4S3-H5S4>can be accessed Control Panel\Network and Internet\Network Connections->Status->Details, IPv4 Default Gateway. These are based on the Verizon Fios Router login 12/22.
H4S1: Access control:
Verizon: Block access to the Internet services from within the LAN. 5 columns: Networked Computer/Device, Network Access, Protocols, Status, Action, with the ability to add # a new blocked device.
H4S2: Port forwarding:
Verizon: This feature enables applications (Games, Webcams, IM & Others) by opening a tunnel between remote (Internet) computers and a specific device port inside your local area network(LAN). Hu: This page allows you to create port forwarding rules from an IPv4 address on the server to a specific | custom port.
H4S3: IPv6 Pinholes:
Verizon: This feature enables “outside-to-inside” access for IPv6 | services so that an “outside” Internet service (gaming, video, etc.) can access a specific “inside” | home client device & port in your local area | network. Hu: IPv6 Pinhole rules have 3 settings: external | host, internal | host, and application / ports.
H4S4: Port triggering:
Verizon: Trigger opening of ports for incoming data. Hu: Protocol | Outgoing Trigger Ports | Incoming Ports to Open | Action.
H4S5: DMZ Host:
Hu: Allow a single networked computer /device to be fully exposed to the Internet.
Note: If you have purchased a group of Static IPv4s and have enabled Static NAT for all your Static IPv4s, do NOT enable the DMZ IPv4 Host feature.
DMZ IPv4 Host: Enable | Select Host<a-computer>, any on the network<fbno> | IPv4 address, to confirm its identity.
Enabling DMZ Host is a security risk. When a computer or device on your network is the DMZ Host, it is directly exposed to the Internet and loses much of the protection of the Gateway firewall. If it is compromised, it can also be used to attack other devices on your home network. Click “Enable DMZ Host” to confirm.
H4S6: Remote administration:
Verizon: Configure Remote Administration to the router. Attention: With Remote Administration enabled, your network will be at risk from outside attacks. Allow Incoming WAN Access to Web-Management. 2 options, to use primary HTTPS port<443>or secondary HTTPS port<8443>Diagnostic Tools: Allow Incoming WAN ICMP Echo Requests (e.g. pings and ICMP traceroute queries), Allow Incoming WAN UDP Traceroute Queries; Hu: The diagnostic | tool are enabled by default.
H4S7: Static NAT:
Add NAT/NAPT Rule: Set up a Local Host, a Public IPv4 Address, and check Enable Port Forwarding For Static NAT.
H4S8: Security log:
Hu: Contains almost 20 logs per 5 minutes during active use times<magnitude>
H4S9: Advanced settings:
H4S10: Public IP inbound re-routing to device lit-rev<Torogi, a-r>:
Torogi<6:46>: Use your router settings<H3S5>to find the public | address of the router. Look for the setting path: Forward Rules->Port.Mapping-Configuration:
H5S1: Select HTTP<Web-Server>: Hu: This is the correct way to do it. 12/6/22: First attempt to set a port forwarding<H4S2>did not permit public-IP to display WAMP-www 12/6/22. Hu<r: King Hd News>: the prevailing | theory folk<fbno>is that all IPs, being as they are registered, are accessible | by-default, and the firewalls, on the router, or local | computer, of the user, close off certain | access, or, if it’s a good | NAT<#v-T>, it will shut off all ports, of all IPs, public and private, or of just the private | path, to the public | IP.
H6S1: When this rule is disabled, devices connected to the router will # see the router | settings<q.tum-shift>when the router’s public | IP is visited, while devices connected to the internet outside of the router will be timed | out. This is regardless of the Windows Security Advanced Inbound settings<H3S7-H4S1>on the web.server-device, which is consistent with our thesis<H3S6>that the router firewall is the first line of defense #n-p
According to https://192.168.1.1/#/advanced/arptable, which has the columns IPv4 Address, MAC Address, and device.internal-params, the assignment of IPv4-Addresses, external-redundantly, to each device is by its unique | MAC-Address, which is actually the core.unique–identifier<malpractice>at all levels. Theoretically, it should be possible to build an index of all MAC-addresses, and give every device a public IP, upon which it can be discovered<cmu.edu, a-r>: A MAC (Media Access Control) address, sometimes referred to as a hardware or physical address, is a unique, 12-character alphanumeric attribute that is used to identify individual electronic devices on a network. An example of a MAC address is: 00-B0-D0-63-C2-26.
Hu: As of 12/10/22, I have not found a way to whitelist.by-IP at the level of the Verizon firewall; initial Google search is not | promising. The public IP can be set to forward to a private by a specific port #, but there is no way # to make this forwarding | action trigger based on user–IP.
H3S6: Troubleshooting the web.data-pathway<Turings>:
Hu: This core | utilities pathway is the least | documented in human history, and several thematic problems present:
H4S1: Lack of transparency of component nomenclature and E:
One component may be called another, and the changes in settings of one may affect another.
H4S2: Discriminatory allowance at various firewall tiers:
Upon cursory glance as of 12/6/22, it appears most of these discriminatory | allowances are circumventable. Basically, there is a non-transparent reputation | system with a pay.to-play,scheme, and quite a bit of oligarchy, and collusion, to prop up a particular reputation system that benefits the .com-registrar, for historical | reasons, an illegal | monopoly and invalid | moat.
H5S1: First circumvention: usage of IETF-pathways:
Hu: There is a small handful of non.greedy-individuals involved, at the ratio of about 10^5:1, who created certain | democratic | pathways of q.tum–tunneling.
H5S2: Second circumvention: q.tum-reliance:
Hu: Most ISPs will reveal a settings page to the user, since it’s their device, not the router, or tower, that handles most of the q.tum-settings. This can be used to the user’s advantage.
Assuming one side of a symmetrical pathway:
Some data starts internal to my device, and upon a user.interface–triggers, the data will be packaged, and fired, with a destination | specified.
H6S1: Request target line:
- The request target, usually a URL, or the absolute | path of the protocol, port, and domain are usually characterized by the request context. The format of this request target varies between different HTTP methods. It can be
- An absolute | path, ultimately followed by a
'?'and query string. This is the most common form, known as the origin form, and is used with
POST / HTTP/1.1
GET /background.png HTTP/1.0
HEAD /test.html?query=alibaba HTTP/1.1
OPTIONS /anypage.html HTTP/1.0
- A complete | URL, known as the absolute form, is mostly | used with
GETwhen connected to a proxy.
GET https://developer.mozilla.org/en-US/docs/Web/HTTP/Messages HTTP/1.1
- The authority | component of a URL, consisting of the domain name and optionally the port (prefixed by a
':'), is called the authority form. It is only used with
CONNECTwhen setting up an HTTP tunnel.
CONNECT developer.mozilla.org:80 HTTP/1.1
- The asterisk form, a simple asterisk (
'*') is used with
OPTIONS, representing the server as a whole.
OPTIONS * HTTP/1.1
- An absolute | path, ultimately followed by a
H6S2: Hu: There are 2 ways to specify a target.absolute–path, depending on whether that path is local or global; if global, a full protocol.led-origin,URL<Turing> has to be used, and this corresponds, in the registrar’s db, with an effective–IP<Turing>
Hu: The HTTP-req is transported to the device‘s own router, which will recognize it as a request, and associate with it<ded>the IP of the device, and itself.
H5S3: Arrival to tower:
Hu: At the tower, the domain | name of the target will be read, and searched through an index | table which contains # that domain | name, the IP-address, and the registrar | info, which tells the utility | company which house to send the payload<malpractice-laden!> Security-wise, all of this data can be easily | compromised and is riskier than bank | data<Turing-dirty>. It’s also possible that the return | address is associated with the source at this step, but, bear in mind, internal | GETs can also be answered.
H5S4: Arrival to destination router:
Hu: The tower will be able to pinpoint the exact.destination–router from its address, a q.tum–E , and will forward the address for the router to provide a response. Here, several blockages may happen: H6S1: The router directly denies the request, because it categorically does not answer them<10%><malpractice>
H5S5: Arrival to the destination device:
Hu: If the router has the private | IP of the device<lawl>, which a working router will, 100%, and the request has not been blocked, then it will be able to # forward the request to that device. This works, more often than here, when the device is the request | source, which means the success rate of responses is higher than that of requests, a paradoxical.rate-limiting,fallacy<malpractice>. In other words, we know it can do it, but when the device is receiving a ping from the outside, a different pathway is used, that we have to manually | defined, because the response pathway<tips-tricks>is hard-coded and not amenable to even a micro.bit–change<malpractice>. When reconstructing this pathway, via soft-coding, we run into the bad.NAT-fallacy, or lack of programming skill, as the NAT does not exist<meme>!
H6S1: Searching the file | pathway:
Hu: WAMP must, at some point, receive the request from the device | entry point, such as the internal | Wifi-receiver, and point the request, by searching its own index, by the provided name or IP<WP.MIC-H2S114,H3S2>This is handled by Apache’s HTTP server, httpd-vhosts, among other files, in the Apache folder, and, to some extent, the ran–script # as well as default windows folder options<Turing>Fin.v-3
H4S4: Mobile devices:
H5S1: When mobile devices # disconnect from LTE and reconnect, their IP-address is changed; both IPv4 and IPv6; tested 12/10/22 twice, separately, on Verizon LTE. This means that their IP is not static on LTE, and cannot be hard | coded; a similar issue exists when mobile devices change to a different remote | Wifi, as they are more likely to be mobile.
H5S1: Mobile-accommodation: we will need some fallback-case when an incoming connection arrives from an unrecognized IP; either the user logs in, or, more conveniently, surrenders its MAC-address, and we can use this to identify the user. Need research to see which firewall levels allow entry by MAC #<Turing>
H3S7: Windows Firewall lit-rev:
Hu: Another level of application and port control # is at the device | level through the level of the Windows Defender Firewall, which is the second | line of defense, in terms of officiated | firewalls<12/6/22>The Windows Firewall is mostly collusion–based; malware that Windows approves of<a-sentence>will have a shortcut, via some SDK-dev, to have a direct | backdoor through the Windows Firewall, which is otherwise cracked in its fervor<a-sentence>. The purpose of the Firewall, explicitly, is to protect one’s computer’s files from direct access, including read, but more so<mal-practice>, write permission to external sources.
H4S1: Inbound rule: port 80:
Per the advice of<King Hd News>, I opened Windows Security->Advanced Settings->Inbound Rules->New Rule->Port->TCP->Specific local port, 80, allow the connection, following his instructions at<7:05>or so. [D] shows the settings.
H5S1: All desktop | applications that I’ve installed, which have communications functionality, such as games, chat apps, Zoom, and my web | browsers, have installed inbound rules, without explicitly asking<mal-practice>, based on my review of the list.
⭐ H5S2: When this rule is enabled, all devices, from any internet, inside and outside the router, will be able to access the Apache web server on the web.server–comp, provided that Apache also has all permissions, relevant, enabled<H4S2, redir #>When it is disabled, external | devices will be timed out, provided the port | forwarding is enabled in<H3S5.H4S10-H5S2>, and so will internal | devices, since the router | firewall screen is skipped, and users will be timed out, at the level of that web.server-comp, by the Windows Firewall<Turing-major>
Hu: By combining the scope | tab in the properties | window of the particular | inbound-rule, we can convert the rule from open–access to whitelist | only by changing the remote | IP setting to ‘these IP addresses’ and specifying only the addresses, from connectees, that we wish to allow #
H6S1: Testing //
H4S2: Apache as an extension of Windows Firewall:<WP.MIC-H3S3>
The Godfather – Great Scene – 1972 When Michael Corleone Takes Command https://www.youtube.com/watch?v=oeBHiJeshcg
King HD News: https://www.youtube.com/watch?v=gNC80QdLK48