Maand: juni 2019

Geplaatst op

Public IPv4 subnet with Fritz!Box

Port forwarding kapot

De Engelstalige versie heeft het hele verhaal, hier mijn stappen om te voorkomen dat de Fritzbox een duplicaat apparaat krijgt. Zo’n duplicaat apparaat (dezelfde hostname met twee MAC-adressen) zorgt voor een heel irritante foutmelding bij het aanmaken van een nieuwe portforwarding of het aanpassen van een bestaande:

Een publiek IPv4 toewijzen

Voor Yunohosts met Armbian op OPi Zero’s volg ik bij benadering het volgende stappenplan:

  • Gewoon aansluiten en een adres per DHCP laten toewijzen
  • Blijf van de hostname af in de Fritzbox
  • Configureer het systeem via SSH op het locale IP
  • Zorg dat zowel een verbinding via ethernet als via seriele kabel beschikbaar is
  • Gebruik nmtui om het publieke IP in te richten
    • Activeer de nieuwe inrichting nog niet
  • Maak de ethernetkabel los
  • Gebruik de seriele verbinding om het apparaatje af te sluiten
  • Wacht totdat de Fritzbox het apparaatje van actieve naar inactieve aansluitingen verplaatst heeft in de thuisnetwerk-instellingen
  • Verwijder het apparaat uit de lijst met apparaten
    • Dat kan enkel wanneer de FB denkt dat het apparaat inactief is
    • Het heeft enkel effect wanneer de naam van het apparaat niet veranderd is vanaf de eerste keer dat de FB het apparaat gesignaleerd heeft
    • Soms helpt het de FB eens te rebooten, maar niet altijd, en het maakt het proces ook niet altijd sneller
  • Zodra je ‘m verwijderd hebt, sluit de ethernetkabel weer aan
  • Zet het apparaatje weer aan . network manager gebruikt de nieuwe configuratie om de netwerkaansluiting in te richten
    • Soms zie je het apparaat niet direct staan, omdat het met een naam gebaseerd op het IP-adres in de lijst gezet wordt
    • Pas de (onhandige) naam niet aan
  • Nu is het apparaat te bereiken op het publieke IP. Het inrichten van port forwardings mag geen problemen opleveren.

Troubleshooting

Print this entry

Geplaatst op

Fediverse met Nextcloud/nginX op Yunohost part II

Het resultaat van deel I was dat ik gebruikers op dezelfde server kon vinden: iedereen die een account op online.osba.nl heeft. Leuk, maar dat was niet wat ik voor ogen had. De afgelopen weken heb ik zo nu en dan een blik op het probleem geworpen, in de hoop dat me een makkelijke oplossing onder ogen zou komen. Helaas.

Vanavond heb ik er meer tijd dan ik had gehoopt besteed, maar ik heb wel een deel van de (weg naar de) oplossing gevonden. De test op webginger.net geeft nu een nuttig resultaat terug:

https://webfinger.net/lookup/?resource=wbk%40online.osba.nl

geeft:

Request log

18:20:13 Looking up WebFinger data for acct:wbk@online.osba.nl
18:20:13 GET https://online.osba.nl/.well-known/webfinger?resource=acct%3Awbk%40online.osba.nl

JSON Resource Descriptor (JRD)

{
  "subject": "acct:wbk@online.osba.nl",
  "links": [
    {
      "rel": "self",
      "type": "application/activity+json",
      "href": "http://online.osba.nl/nextcloud/nextcloud/index.php/apps/social/@wbk"
    },
    {
      "rel": "http://ostatus.org/schema/1.0/subscribe"
    }
  ]
}

Dat was telkens 404, niets gevonden.

Meer details zijn (in het Engels) te vinden Yunohost forum, maar het belangrijkste deel is de benodigde configuratie en waar je het moet laten. Het configuratiebestand waar het om gaat is de nginx-configuratie op

/etc/nginx/conf.d/online.osba.nl.conf

Er zijn twee servers gedefinieerd, de onversleutelde op poort 80 en de versleutelde verbinding op poort 443. De eerste had na het installeren via Yunohost / Nextcloud alle redirects cadeau gekregen, die op poort 443 niets. Ik vond het opvallend, maar bij gebrek aan kennis van nginx deed het ook geen alarmbellen rinkelen. Het blijkt dat de verwijzingen op beid e servers gedefinieerd moeten staan, anders werkt het niet via TLS. Bovendien moet het een combinatie van doorverwijzing en herschrijven van de URL zijn:

Het gecombineerde stanza ziet er zo uit:

location = /.well-known/webfinger {
  rewrite ^ https://online.osba.nl/nextcloud/public.php?service=webfinger&$1 last; # $1 will use the first parameter (?resource=…)
}

Stop het stukje tussen de ‘include …’ en ‘log ..’ regels.

Ookal werkt de test op webfinger.net nu, het lukt nog niet om op de ene Nextcloud een gebruiker op een andere Nextcloud-server te vinden.

Wordt vervolgd…

Print this entry