Perguntas[networking](computer)

Esta questão está relacionada às redes MoCA (ou mesmo TV a cabo).

Entendo que um divisor coaxial de 2 vias sem amplificação fornece apenas 50% do sinal para cada cabo. O que acontece se eu usar um divisor de 3 vias, mas conectar apenas dois cabos de saída (a terceira saída é para possível expansão futura, mas não é necessária no momento)? Cada uma das duas saídas recebe 33% ou 50%?

Isso se refere ao superprovisionamento com o objetivo de expansão futura. É melhor obter apenas o splitter mínimo necessário no momento e atualizar posteriormente, conforme necessário, ou é aceitável adquirir um splitter que possa lidar com mais saídas no futuro?

Estou tentando configurar meu roteador TP VPN Festa para se conectar à LAN usando OpenVPN. Configurei o OpenVPN no roteador e no celular. O roteador Festa está atrás do roteador do provedor de internet. Conectar-me ao Wi-Fi a partir do ponto de acesso atrás do roteador Festa me permite conectar usando OpenVPN. Conectar-me ao Wi-Fi a partir do roteador do provedor de internet também me permite conectar usando OpenVPN. Portanto, a porta no roteador do provedor de internet está aberta e permite acesso ao roteador VPN, presumo.

Quando tento conectar usando os dados do meu celular, que é o alvo principal para o que quero usar o OpenVPN (como se eu estivesse no local), ele não conecta.

Anexei um diagrama da rede e o log do aplicativo OpenVPN quando tento me conectar pela rede do celular. Por favor, informe-me quais outras informações seriam necessárias e relevantes. Percebi que o log mostra as tentativas de conexão com o IP do roteador VPN, mas não vejo o IP público ou, no meu caso, o endereço DynDns. Não sei por onde ou como começar a solucionar o problema nesta situação.

Registro do OpenVPN:

[Apr 11, 2025, 17:29:12] START CONNECTION
[Apr 11, 2025, 17:29:12] ----- OpenVPN Start -----
OpenVPN core 3.10.5 ios arm64 64-bit
[Apr 11, 2025, 17:29:12] OpenVPN core 3.10.5 ios arm64 64-bit
[Apr 11, 2025, 17:29:12] Frame=512/2112/512 mssfix-ctrl=1250
[Apr 11, 2025, 17:29:12] NOTE: This configuration contains options that were not used:
[Apr 11, 2025, 17:29:12] Unsupported option (ignored)
[Apr 11, 2025, 17:29:12] 0 [resolv-retry] [infinite]
[Apr 11, 2025, 17:29:12] 1 [persist-key]
[Apr 11, 2025, 17:29:12] EVENT: RESOLVE
[Apr 11, 2025, 17:29:12] Contacting 192.168.1.11:1194 via UDP
[Apr 11, 2025, 17:29:12] EVENT: WAIT
[Apr 11, 2025, 17:29:12] Connecting to [192.168.1.11]:1194 (192.168.1.11) via UDP
[Apr 11, 2025, 17:29:22] Server poll timeout, trying next remote entry...
[Apr 11, 2025, 17:29:22] EVENT: RECONNECTING
[Apr 11, 2025, 17:29:22] EVENT: RESOLVE
[Apr 11, 2025, 17:29:22] Contacting 192.168.1.11:1194 via UDP
[Apr 11, 2025, 17:29:22] EVENT: WAIT
[Apr 11, 2025, 17:29:22] Connecting to [192.168.1.11]:1194 (192.168.1.11) via UDP
[Apr 11, 2025, 17:29:32] Server poll timeout, trying next remote entry...
[Apr 11, 2025, 17:29:32] EVENT: RECONNECTING
[Apr 11, 2025, 17:29:32] EVENT: RESOLVE
[Apr 11, 2025, 17:29:32] Contacting 192.168.1.11:1194 via UDP
[Apr 11, 2025, 17:29:32] EVENT: WAIT
[Apr 11, 2025, 17:29:32] Connecting to [192.168.1.11]:1194 (192.168.1.11) via UDP
[Apr 11, 2025, 17:29:42] Server poll timeout, trying next remote entry...
[Apr 11, 2025, 17:29:42] EVENT: RECONNECTING
[Apr 11, 2025, 17:29:42] EVENT: RESOLVE
[Apr 11, 2025, 17:29:42] Contacting 192.168.1.11:1194 via UDP
[Apr 11, 2025, 17:29:42] EVENT: WAIT
[Apr 11, 2025, 17:29:42] Connecting to [192.168.1.11]:1194 (192.168.1.11) via UDP
[Apr 11, 2025, 17:29:52] Server poll timeout, trying next remote entry...
[Apr 11, 2025, 17:29:52] EVENT: RECONNECTING
[Apr 11, 2025, 17:29:52] EVENT: RESOLVE
[Apr 11, 2025, 17:29:52] Contacting 192.168.1.11:1194 via UDP
[Apr 11, 2025, 17:29:52] EVENT: WAIT
[Apr 11, 2025, 17:29:52] Connecting to [192.168.1.11]:1194 (192.168.1.11) via UDP
[Apr 11, 2025, 17:30:02] Server poll timeout, trying next remote entry...
[Apr 11, 2025, 17:30:02] EVENT: RECONNECTING
[Apr 11, 2025, 17:30:02] EVENT: RESOLVE
[Apr 11, 2025, 17:30:02] Contacting 192.168.1.11:1194 via UDP
[Apr 11, 2025, 17:30:02] EVENT: WAIT
[Apr 11, 2025, 17:30:02] Connecting to [192.168.1.11]:1194 (192.168.1.11) via UDP
[Apr 11, 2025, 17:30:12] EVENT: CONNECTION_TIMEOUT [ERR]
[Apr 11, 2025, 17:30:12] EVENT: DISCONNECTED
[Apr 11, 2025, 17:30:12] EVENT: CORE_THREAD_DONE
[Apr 11, 2025, 17:30:12] EVENT: DISCONNECT_PENDING
[Apr 11, 2025, 17:30:12] Raw stats on disconnect:
  BYTES_OUT : 840
  PACKETS_OUT : 60
  CONNECTION_TIMEOUT : 1
  N_RECONNECT : 5
[Apr 11, 2025, 17:30:12] Performance stats on disconnect:
  CPU usage (microseconds): 119098
  Network bytes per CPU second: 7053
  Tunnel bytes per CPU second: 0

Em uma rede local sem fio, se dois dispositivos quiserem se comunicar (ou se um quiser se comunicar com um dispositivo em uma rede externa, como a Internet), eles precisam enviar as informações que estão tentando comunicar ao roteador e, como é uma rede sem fio, isso é feito transmitindo os dados na forma de ondas eletromagnéticas.

Como a forma de todos os dados transmitidos será, em última análise, binária (1 e 0), não podemos simplesmente escolher uma combinação específica de frequência, amplitude e fase de ondas EM para "1" e outra combinação para "0", pois o roteador precisa diferenciar entre os dados que chegam de um dispositivo do outro, além de precisar enviar informações para um dispositivo específico na rede em vez de todos eles.

Pelo que entendi, isso é feito convertendo os dados digitais (em binário) em um sinal portador analógico (onda EM) e, então, sobrepondo uma onda "moduladora" a essa onda portadora, onde as especificidades de como a onda moduladora altera o sinal modulado final criam sinais únicos entre os dispositivos na rede e o roteador.

Esses sinais também precisam ser "demodulados" e então convertidos de volta de ondas EM analógicas para digitais (binárias aqui). Um dispositivo que modula e demodula esses sinais é um modulador-demodulador (modem).

Minha pergunta é:

• São as NICs que realizam esses processos de modulação e demodulação ao enviar/receber dados?
• Se sim, isso não os torna modems?
• Caso contrário, qual hardware é responsável por esses processos?

Tenho um roteador TP Link AC 1200 conectado ao fio LAN da parede. Eu uso isso para obter conexão Wi-Fi.

Quero estender o sinal dele e me deram um D-Link DAP 1360 para usar como extensor. Mas realmente não consigo descobrir como configurá-lo.

O D-Link DAP 1360 era usado anteriormente para estender outro sinal de Wi-Fi que chega ao meu apartamento. Tentei seguir instruções online, mas só fica incompleto.

Por exemplo, nesta página de instruções, ele apenas vai para qual pode ser a senha para o login. Eu tentei o padrão 0000e admin, ou deixar o campo em branco e sem sorte.

EDIT: Fiz uma reinicialização física do dispositivo fixando o botão de reinicialização, mas quando acesso a 192.168.0.50página de login e deixo o administrador e a senha em branco para fazer login, ele retorna um can't reach this page message.

O que posso fazer?

Gostaria de pedir ajuda para entender como funciona a rede que tenho. O diagrama de conexão é bem simples, na verdade:

Cabo óptico ---> [Zyxel ONT] ---> Cabo Ethernet ---> [Porta WAN do roteador] ---> Cabos Ethernet das portas LAN ---> [Computadores]

Quero abrir a página de login de configuração do ZyXEL PM5100-T0 ONT. https://www.prodottiperisp.it/files/PM5100-T0_User-s_Guide_Version-5.42.pdf

Embora eu não tenha as informações de login e não consiga fazer login, sou uma pessoa curiosa e gostaria de entender como acessá-lo.

• O ONT está se comunicando com o roteador via PPPoE.
• De dentro da LAN não consigo ver o IP do ONT que está conectado à porta WAN.

Aqui estão minhas perguntas e ideias:

1. O ONT tem um intervalo de IP diferente da minha LAN?
   Provavelmente sim.

2. Preciso conectar o ONT à LAN e não à WAN para abrir a página de login?
   Sei que existe um firewall entre a WAN e a LAN, o objetivo aqui é abrir a página de login, não deixá-la conectada à LAN.

3. Qual a função do PPPoE se eu conectar o ONT à LAN do roteador?
   Se eu configurar minha LAN para ter o mesmo intervalo de IP do ONT, o PPPoE me impedirá de conectar à página de login?

4. Conectar o ONT à LAN é a maneira correta de fazer isso? Ou preciso fazer algo mais?
   Como configurar algo no roteador para permitir que o lado da LAN veja a página de login no lado da WAN para que o PPPoE continue ativo?

5. Como funciona a conexão de rede PPPoE?
   Sei pelo provedor de internet que a conexão usa endereços MAC para identificar as conexões dos clientes. As informações de login e VLAN para PPPoE são idênticas para todos os clientes.

• Qual MAC ele está usando? O MAC do meu roteador ou o MAC do ONT?
• O ONT é transparente para o ISP e eles estão fornecendo o IP público diretamente para meu roteador porque o roteador está fazendo login via PPPoE?

Meu objetivo aqui é entender como isso funciona. Embora eu tenha algum conhecimento de rede, PPPoE é novidade para mim.

Para evitar a exposição do lado da LAN à internet, desconectarei o cabo óptico durante os experimentos.

Obrigado.

Quando quero rastrear um IP restrito pelo governo, estou vendo apenas o IP do meu roteador local e os endereços IP privados do NAT. Depois disso, tudo o que vejo são asteriscos por todo lado. Este é meu exemplo de saída:

traceroute to x.com (172.66.0.227), 30 hops max, 60 byte packets
1  home (192.168.1.1)  0.332 ms  0.437 ms  0.553 ms
2  172.x.x.x (172.x.x.x)  2.862 ms  2.837 ms  2.859 ms
3  * * *
4  * * *
5  * * *
6  * * *

Normalmente vejo pelo menos um endereço ISP depois do IP privado, mas há apenas dois IPs neste caso . Não chegou nem ao servidor ISP? De onde vieram as respostas de tempo limite do ICMP? Meu roteador não tem nenhuma configuração especial para isso. Gostaria de saber como isso pode ser possível.

Gostaria de fazer um túnel do meu tráfego de internet do meu PC Windows no meu escritório por meio de um servidor remoto, de preferência com L2TP (sem IPsec, possivelmente usando a modificação do registro ProhibitIpSec). Um pouco como um serviço como o serviço AAISP L2TP .

Normalmente, para propósitos de VPN, eu diria que usar um protocolo não criptografado sozinho é totalmente inapropriado. No entanto, não vou acessar recursos sensíveis ou de texto simples pelo túnel (como compartilhamentos de arquivos), só vou enviar tráfego que, em circunstâncias normais, seria enviado pela internet em sua forma bruta de qualquer maneira. (E de fato será, somente após passar pelo servidor do túnel).

Portanto, e por favor me corrija se eu tiver esquecido de algo, mas a única preocupação aqui é a segurança das credenciais de login L2TP conforme elas são transmitidas? Ter essas credenciais roubadas não seria o ideal, pois alguém poderia então potencialmente se conectar ao servidor de túnel por si próprio. (Embora eu tenha alguma restrição de firewall em conexões de entrada).

A questão: O método de troca de credenciais no L2TP (é MS CHAPv2?) é seguro o suficiente para ser usado sem criptografia adicional e há alguma falha de segurança importante no meu plano acima?

Estou usando um TP Link Archer C50 e quero configurá-lo no modo bridge. Meu objetivo é ter a "fonte" da internet vindo por um cabo para o TP-Link. Ele então envia essa rede via WiFi e funciona como um switch quando outros dispositivos são conectados via cabo.

Até agora, consegui fazer isso funcionar, e posso verificar que alguns dispositivos obtêm os endereços IP corretos. O problema é que, para alguns dispositivos, isso não está funcionando, e eles estão obtendo o endereço IP errado. A suspeita é que o TP-Link de alguma forma funciona como um servidor DHCP e tenta fornecer endereços IP locais.

Usando # tcpdump src port bootps, eu estava procurando respostas para solicitações de servidor DHCP. Quando conecto meu laptop ao WiFi, recebo a seguinte linha:

15:27:26.422322 IP 192.168.0.1.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 548

Durante a configuração do TP-Link, desabilitei manualmente o DHCP. O que está causando essas respostas locais do DHCP?

Sou bem novo no assunto de redes, então espero conseguir explicar o assunto corretamente.

Tenho uma rede que é um roteador conectado a um switch que tem algumas portas LAN onde os PCs são conectados e 2 APs.

Criei as VLANs 20 e 39. No entanto, quando crio a rede e atribuo a VLAN, por exemplo, 10, 20 ou 40, não consigo mais fazer login na WLAN. Quando não há uma VLAN atribuída à rede WLAN, funciona bem.

Meu objetivo é:

que todas as VLANs, exceto a convidada, podem acessar a impressora, mas as demais VLANs não podem acessar umas às outras, apenas se conectar entre os PCs da VLAN e, claro, à internet.

Meu equipamento é:

• Roteador ISP que está atribuindo DHCP no momento
• Interruptor TP Link Festa FS328GP
• 2 AP TP Link Festa F65

Como fazer isso funcionar?

Para começar, não sou muito versado em redes ou gerenciamento de servidores, então tenham paciência se isso parecer elementar para alguns de vocês.

Eu configurei uma instância do Wireguard rodando em um VPS, usando Debian. Minha intenção é usá-lo para privacidade na internet, pois as opções atuais à minha disposição são inadequadas.

Eu tentei e falhei várias vezes para fazer o Wireguard funcionar corretamente, pois meu(s) dispositivo(s) cliente(s) não conseguem se conectar à internet. Eu consigo me conectar ao servidor sem problemas, o Wireguard mostra o cliente conectado e, sempre que ele está conectado, eu consigo fazer SSH no servidor sem problemas a partir do dispositivo cliente. Eu tentei adicionar um DNS, especificamente o do Google (8.8.8.8, 8.8.4.4), mas isso também não ajuda. Eu não consigo nem fazer ping no DNS quando ele está definido.

Abaixo está minha configuração atual de servidor e cliente:

Cliente:

[Interface]
PrivateKey = [redacted]
Address = 10.0.0.2/32

[Peer]
PublicKey = [redacted]
Endpoint = [redacted]:51820
AllowedIPs = 0.0.0.0/0

Servidor:

PrivateKey = [redacted]
Address = 10.0.0.1/24
ListenPort = 51820

[Peer]
PublicKey = [redacted]
AllowedIPs = 10.0.0.2/32

Qualquer ajuda sobre isso seria apreciada. Já faz um tempo que estou batendo a cabeça na parede sobre isso.

Tabela de roteamento do servidor:

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 [redacted]/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute
       valid_lft forever preferred_lft forever
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether [redacted] brd ff:ff:ff:ff:ff:ff
    inet [redacted]/25 brd [redacted] scope global dynamic enp1s0
       valid_lft 73624sec preferred_lft 73624sec
    inet6 [redacted]/64 scope link
       valid_lft forever preferred_lft forever
5: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none
    inet 10.0.0.1/24 scope global wg0
       valid_lft forever preferred_lft forever

Saída das tabelas de IP do servidor:

Chain INPUT (policy DROP 989 packets, 54363 bytes)
 pkts bytes target     prot opt in     out     source               destination
 630K  320M ufw-before-logging-input  0    --  *      *       0.0.0.0/0
   0.0.0.0/0
 630K  320M ufw-before-input  0    --  *      *       0.0.0.0/0            0.0.0.0/0
 213K   12M ufw-after-input  0    --  *      *       0.0.0.0/0            0.0.0.0/0
 212K   12M ufw-after-logging-input  0    --  *      *       0.0.0.0/0
  0.0.0.0/0
 212K   12M ufw-reject-input  0    --  *      *       0.0.0.0/0            0.0.0.0/0
 212K   12M ufw-track-input  0    --  *      *       0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     0    --  eth0   *       0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     0    --  eth1   *       0.0.0.0/0            0.0.0.0/0
         state RELATED,ESTABLISHED
Chain FORWARD (policy DROP 5286 packets, 1038K bytes)
 pkts bytes target     prot opt in     out     source               destination
 7518 1184K ufw-before-logging-forward  0    --  *      *       0.0.0.0/0
     0.0.0.0/0
 7518 1184K ufw-before-forward  0    --  *      *       0.0.0.0/0            0.0.0.0/0
 5286 1038K ufw-after-forward  0    --  *      *       0.0.0.0/0            0.0.0.0/0
 5286 1038K ufw-after-logging-forward  0    --  *      *       0.0.0.0/0
    0.0.0.0/0
 5286 1038K ufw-reject-forward  0    --  *      *       0.0.0.0/0            0.0.0.0/0
 5286 1038K ufw-track-forward  0    --  *      *       0.0.0.0/0            0.0.0.0/0
Chain OUTPUT (policy ACCEPT 225 packets, 20892 bytes)
 pkts bytes target     prot opt in     out     source               destination
 370K   75M ufw-before-logging-output  0    --  *      *       0.0.0.0/0
    0.0.0.0/0
 370K   75M ufw-before-output  0    --  *      *       0.0.0.0/0            0.0.0.0/0
 3564  350K ufw-after-output  0    --  *      *       0.0.0.0/0            0.0.0.0/0
 3564  350K ufw-after-logging-output  0    --  *      *       0.0.0.0/0
   0.0.0.0/0
 3564  350K ufw-reject-output  0    --  *      *       0.0.0.0/0            0.0.0.0/0
 3564  350K ufw-track-output  0    --  *      *       0.0.0.0/0            0.0.0.0/0
  363 36318 ACCEPT     0    --  *      *       0.0.0.0/0            0.0.0.0/0
Chain ufw-after-input (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ufw-skip-to-policy-input  17   --  *      *       0.0.0.0/0
   0.0.0.0/0            udp dpt:137
    0     0 ufw-skip-to-policy-input  17   --  *      *       0.0.0.0/0
   0.0.0.0/0            udp dpt:138
    2    84 ufw-skip-to-policy-input  6    --  *      *       0.0.0.0/0
   0.0.0.0/0            tcp dpt:139
    6   308 ufw-skip-to-policy-input  6    --  *      *       0.0.0.0/0
   0.0.0.0/0            tcp dpt:445
    0     0 ufw-skip-to-policy-input  17   --  *      *       0.0.0.0/0
   0.0.0.0/0            udp dpt:67
    0     0 ufw-skip-to-policy-input  17   --  *      *       0.0.0.0/0
   0.0.0.0/0            udp dpt:68
    4  8908 ufw-skip-to-policy-input  0    --  *      *       0.0.0.0/0
   0.0.0.0/0            ADDRTYPE match dst-type BROADCAST
Chain ufw-after-logging-forward (1 references)
 pkts bytes target     prot opt in     out     source               destination
  327 46259 LOG        0    --  *      *       0.0.0.0/0            0.0.0.0/0
         limit: avg 3/min burst 10 LOG flags 0 level 4 prefix "[UFW BLOCK] "
Chain ufw-after-logging-input (1 references)
 pkts bytes target     prot opt in     out     source               destination
  219 11136 LOG        0    --  *      *       0.0.0.0/0            0.0.0.0/0
         limit: avg 3/min burst 10 LOG flags 0 level 4 prefix "[UFW BLOCK] "
Chain ufw-before-forward (1 references)
 pkts bytes target     prot opt in     out     source               destination
 1927  126K ACCEPT     0    --  *      *       0.0.0.0/0            0.0.0.0/0
         ctstate RELATED,ESTABLISHED
    0     0 ACCEPT     1    --  *      *       0.0.0.0/0            0.0.0.0/0
         icmptype 3
    0     0 ACCEPT     1    --  *      *       0.0.0.0/0            0.0.0.0/0
         icmptype 11
    0     0 ACCEPT     1    --  *      *       0.0.0.0/0            0.0.0.0/0
         icmptype 12
  305 19540 ACCEPT     1    --  *      *       0.0.0.0/0            0.0.0.0/0
         icmptype 8
 5286 1038K ufw-user-forward  0    --  *      *       0.0.0.0/0            0.0.0.0/0
Chain ufw-before-input (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     0    --  lo     *       0.0.0.0/0            0.0.0.0/0
 211K  188M ACCEPT     0    --  *      *       0.0.0.0/0            0.0.0.0/0
         ctstate RELATED,ESTABLISHED
   56 19597 ufw-logging-deny  0    --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate INVALID
   56 19597 DROP       0    --  *      *       0.0.0.0/0            0.0.0.0/0
         ctstate INVALID
    0     0 ACCEPT     1    --  *      *       0.0.0.0/0            0.0.0.0/0
         icmptype 3
    0     0 ACCEPT     1    --  *      *       0.0.0.0/0            0.0.0.0/0
         icmptype 11
    0     0 ACCEPT     1    --  *      *       0.0.0.0/0            0.0.0.0/0
         icmptype 12
   11   626 ACCEPT     1    --  *      *       0.0.0.0/0            0.0.0.0/0
         icmptype 8
    0     0 ACCEPT     17   --  *      *       0.0.0.0/0            0.0.0.0/0
         udp spt:67 dpt:68
20848 1252K ufw-not-local  0    --  *      *       0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     17   --  *      *       0.0.0.0/0            224.0.0.251
         udp dpt:5353
    0     0 ACCEPT     17   --  *      *       0.0.0.0/0            239.255.255.250      udp dpt:1900
20848 1252K ufw-user-input  0    --  *      *       0.0.0.0/0            0.0.0.0/0
Chain ufw-before-output (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     0    --  *      lo      0.0.0.0/0            0.0.0.0/0
 193K   42M ACCEPT     0    --  *      *       0.0.0.0/0            0.0.0.0/0
         ctstate RELATED,ESTABLISHED
 1960  219K ufw-user-output  0    --  *      *       0.0.0.0/0            0.0.0.0/0
Chain ufw-logging-allow (0 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 LOG        0    --  *      *       0.0.0.0/0            0.0.0.0/0
         limit: avg 3/min burst 10 LOG flags 0 level 4 prefix "[UFW ALLOW] "
Chain ufw-logging-deny (2 references)
 pkts bytes target     prot opt in     out     source               destination
   56 19597 RETURN     0    --  *      *       0.0.0.0/0            0.0.0.0/0
         ctstate INVALID limit: avg 3/min burst 10
    0     0 LOG        0    --  *      *       0.0.0.0/0            0.0.0.0/0
         limit: avg 3/min burst 10 LOG flags 0 level 4 prefix "[UFW BLOCK] "
Chain ufw-not-local (1 references)
 pkts bytes target     prot opt in     out     source               destination
20844 1243K RETURN     0    --  *      *       0.0.0.0/0            0.0.0.0/0
         ADDRTYPE match dst-type LOCAL
    0     0 RETURN     0    --  *      *       0.0.0.0/0            0.0.0.0/0
         ADDRTYPE match dst-type MULTICAST
    4  8908 RETURN     0    --  *      *       0.0.0.0/0            0.0.0.0/0
         ADDRTYPE match dst-type BROADCAST
    0     0 ufw-logging-deny  0    --  *      *       0.0.0.0/0            0.0.0.0/0            limit: avg 3/min burst 10
    0     0 DROP       0    --  *      *       0.0.0.0/0            0.0.0.0/0
Chain ufw-skip-to-policy-forward (0 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DROP       0    --  *      *       0.0.0.0/0            0.0.0.0/0
Chain ufw-skip-to-policy-input (7 references)
 pkts bytes target     prot opt in     out     source               destination
   12  9300 DROP       0    --  *      *       0.0.0.0/0            0.0.0.0/0
Chain ufw-skip-to-policy-output (0 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     0    --  *      *       0.0.0.0/0            0.0.0.0/0
Chain ufw-track-output (1 references)
 pkts bytes target     prot opt in     out     source               destination
   10   600 ACCEPT     6    --  *      *       0.0.0.0/0            0.0.0.0/0
         ctstate NEW
 1362  162K ACCEPT     17   --  *      *       0.0.0.0/0            0.0.0.0/0
         ctstate NEW
Chain ufw-user-forward (1 references)
 pkts bytes target     prot opt in     out     source               destination
Chain ufw-user-input (1 references)
 pkts bytes target     prot opt in     out     source               destination
19757 1175K ACCEPT     6    --  *      *       0.0.0.0/0            0.0.0.0/0
         tcp dpt:22
   90 13764 ACCEPT     17   --  *      *       0.0.0.0/0            0.0.0.0/0
         udp dpt:51820
Chain ufw-user-limit (0 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 LOG        0    --  *      *       0.0.0.0/0            0.0.0.0/0
         limit: avg 3/min burst 5 LOG flags 0 level 4 prefix "[UFW LIMIT BLOCK]
"
    0     0 REJECT     0    --  *      *       0.0.0.0/0            0.0.0.0/0
         reject-with icmp-port-unreachable
Chain ufw-user-limit-accept (0 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     0    --  *      *       0.0.0.0/0            0.0.0.0/0

Por sugestão do usuário Davidgo, adicionar iptables -t nat -A POSTROUTING -o [YOUR ETHERNET INTERFACE] -j MASQUERADE(interface foi enp1s0no meu caso) e adicionar iptables -I FORWARD -j ACCEPTcorrigiu temporariamente o problema. Após a reinicialização do servidor, essas alterações são revertidas. Tentarei trabalhar em como adicionar essas regras permanentemente.