Comment configurer un routeur de voyage derrière le portail captif d'un hôtel
Autorisez d'abord l'établissement, puis démarrez le tunnel. Vérifiez le mode client, le DNS et ce que reçoit un appareil en aval, plutôt que de vous fier au voyant d'état du routeur.
Vous ouvrez la page d'administration du routeur de voyage et la tentation est de démarrer le VPN immédiatement. Le réseau de l'hôtel a d'autres plans : votre routeur est un client du Wi-Fi de l'établissement, et tant que cette connexion amont n'est pas autorisée, aucun tunnel n'atteint quoi que ce soit. Parcourez les deux étapes dans l'ordre, et le routeur cessera de sembler en panne.
D'abord, vérifiez que le routeur sait faire les deux tâches
Il vous faut un mode client amont, généralement appelé répéteur, client ou WISP, et un client VPN sortant. Ce sont des fonctions différentes de celles d'un serveur VPN, et beaucoup de routeurs bon marché proposent la seconde et non la première.
Dans la page d'administration, trouvez la section WAN ou internet et basculez-la en mode client sans fil. Balayez pour trouver le SSID de l'établissement, rejoignez-le et laissez le routeur prendre une adresse avant de configurer autre chose.
Confirmez la version du micrologiciel pendant que vous y êtes. Les noms de menus changent d'une version à l'autre, et le chemin d'un ancien guide peut ne plus exister même si la fonction existe. Notez le modèle et la version avec votre équipement de voyage. Quand une étape documentée ne correspond pas à l'écran devant vous, la différence de version en est presque toujours la raison.
Ensuite, autorisez la connexion amont
Connectez un ordinateur portable au routeur et ouvrez n'importe quelle page HTTP. Le portail devrait rediriger, et la procédure propre à l'établissement s'applique à partir de là. Certains portails fonctionnent mieux depuis un téléphone que depuis un routeur sans écran, c'est pourquoi le faire depuis un appareil connecté est généralement plus rapide.
Un blocage strict du VPN peut compliquer ce démarrage. Si l'établissement abandonne le trafic du tunnel avant l'autorisation, le client VPN du routeur échouera tant que le portail est en attente, et cet échec est attendu et non une mauvaise configuration.
Utilisez une méthode prise en charge pour le franchir. Retirer plusieurs contrôles à la fois, ou installer un certificat qu'une page de portail propose comme réparation, échange une gêne temporaire contre un problème permanent.
Troisièmement, démarrez le VPN avec un profil qu'il prend en charge
Une fois l'accès ordinaire fonctionnel, démarrez le client VPN du routeur avec le profil qu'il prend réellement en charge. Une configuration WireGuard et un profil OpenVPN ne sont pas interchangeables, et aucun des deux ne peut être importé dans un champ IPsec natif.
Vérifiez trois choses avant de lui faire confiance : le point de terminaison est joignable, le résolveur répond avec la valeur attendue et l'adresse de sortie est celle que vous attendez. La vérification de sortie est la seule qui prouve que le tunnel transporte du trafic et non qu'il est simplement configuré.
curl -sS https://ifconfig.me
cat /etc/resolv.conf
Si le routeur signale une connexion et que l'adresse de sortie est toujours celle de l'établissement, le tunnel ne transporte pas le trafic que vous croyez. Corrigez cela avant d'ajouter des appareils en aval à l'image.
Quatrièmement, testez depuis un appareil en aval
La page d'état du routeur décrit la connexion propre du routeur. Faites une nouvelle requête depuis l'ordinateur portable censé être couvert, et vérifiez IPv4, IPv6 et le résolveur séparément, car un appareil peut être couvert pour une famille et pas pour l'autre.
| Stage | What to verify | Where |
|---|---|---|
| Upstream join | Router has an address from the venue | Router WAN status |
| Portal authorization | A fresh request loads a public page | Connected laptop |
| Tunnel | Egress address changed | Router or laptop |
| Downstream coverage | Laptop resolves and reaches the private resource | Laptop |
Si l'ordinateur portable échoue alors que le routeur réussit, le problème est dans le chemin aval : NAT, DHCP ou une politique de tunnel qui ne couvre que le trafic propre du routeur. Vérifiez que l'ordinateur portable a une adresse issue du pool du routeur, puis que sa passerelle par défaut est le routeur. Un appareil qui détient encore un bail du serveur DHCP de l'établissement est sur un réseau complètement erroné.
Cinquièmement, décidez du repli et conservez la connexion
Testez ce qui se passe quand le portail expire ou que le tunnel tombe. La politique que vous avez choisie doit couvrir le trafic transféré, pas seulement les requêtes que le routeur fait lui-même, sinon un appareil en aval retombera silencieusement sur la connexion de l'établissement.
Conservez la procédure de connexion amont vérifiée avec le routeur, sur papier ou dans une note locale. Un redémarrage au prochain hôtel devient une tâche de deux minutes au lieu d'une nouvelle configuration improvisée. Gardez aussi une copie hors du routeur, car une note stockée uniquement sur l'appareil est indisponible précisément quand l'appareil est ce qui a lâché. Le papier gagne encore dans ce cas.
Notez ensuite les quatre valeurs qui l'ont fait fonctionner : mode amont, procédure du portail, type de profil VPN et vérification de sortie. Ces quatre sont ce dont vous aurez besoin la prochaine fois, et ce sont les quatre les plus difficiles à reconstituer de mémoire.