AWS EC2 Timeout? Løs forbindelsesproblemer nu

At blive mødt af en 'Operation timed out' eller en lignende forbindelsesfejl, når man forsøger at få adgang til sin AWS EC2-server, er en af de mest frustrerende oplevelser for enhver udvikler eller systemadministrator. Man har brug for adgang nu, men serveren svarer simpelthen ikke. Den gode nyhed er, at denne type problem næsten altid skyldes en konfigurationsfejl i netværket, som kan identificeres og rettes systematisk. Denne artikel er din omfattende guide til fejlfinding og løsning af SSH-forbindelsesproblemer til din EC2-instans, så du hurtigt kan komme tilbage til dit arbejde.

De Grundlæggende Årsager til Forbindelsesproblemer

Før vi dykker ned i de mere komplekse netværksindstillinger i AWS, er det vigtigt at udelukke de mest basale fejl. Ofte kan løsningen findes her, hvilket sparer dig for en masse tid og besvær.

• Er din instans kørende? Dobbelttjek i AWS Management Console under EC2 > Instances, at din instans har statussen 'running'.
• Bruger du den korrekte IP-adresse? Verificer, at du bruger den korrekte 'Public IPv4 address' eller 'Public IPv4 DNS' for din instans. Hvis du har genstartet instansen, og den ikke har en Elastic IP tilknyttet, kan den offentlige IP-adresse have ændret sig.
• Er din SSH-nøgle korrekt? Sørg for, at du bruger den korrekte private nøglefil (.pem), der svarer til det nøglepar, du valgte, da du oprettede instansen.
• Har din nøglefil de rigtige tilladelser? På Linux og macOS skal din private nøglefil have restriktive filtilladelser for at SSH-klienten vil acceptere den. Kør kommandoen chmod 400 din-noegle.pem i din terminal for at sikre, at kun du kan læse filen. Uden dette vil mange SSH-klienter afvise at bruge nøglen af sikkerhedsmæssige årsager.

Den Store Synder: Sikkerhedsgrupper (Security Groups)

I langt de fleste tilfælde er synderen en forkert konfigureret Sikkerhedsgruppe. Tænk på en sikkerhedsgruppe som en virtuel firewall, der kontrollerer indgående og udgående trafik for din EC2-instans. Hvis den ikke eksplicit tillader din SSH-forbindelse, vil pakkerne blive droppet, og du vil opleve en timeout.

Sådan Konfigurerer du Indgående Regler Korrekt

Du skal have en 'Inbound rule' (indgående regel), der tillader trafik på TCP-port 22, som er standardporten for SSH. Følg disse trin:

1. Naviger til din instans i EC2-konsollen.
2. Klik på fanen 'Security'.
3. Klik på navnet på den sikkerhedsgruppe, der er tilknyttet din instans.
4. Under fanen 'Inbound rules', klik på 'Edit inbound rules'.
5. Klik på 'Add rule' og konfigurer den som følger:
• Type: Vælg 'SSH'. Dette vil automatisk udfylde Protocol (TCP) og Port range (22).
• Source: Her har du to primære valg. For den bedste sikkerhed skal du vælge 'My IP'. AWS vil automatisk indsætte din nuværende offentlige IP-adresse. Dette sikrer, at kun forbindelser fra din nuværende placering er tilladt. Hvis din IP-adresse ofte ændrer sig, skal du huske at opdatere denne regel.
• Source (Alternativ - Usikkert): Du kan vælge 'Anywhere-IPv4' (0.0.0.0/0). Dette åbner port 22 for hele internettet. Selvom det kan være en hurtig måde at teste på, er det en stor sikkerhedsrisiko, da det udsætter din server for konstante angrebsforsøg. Brug det kun midlertidigt til fejlfinding.
6. Klik på 'Save rules'.

Vent et øjeblik, og prøv at forbinde igen. Dette løser problemet i 9 ud af 10 tilfælde.

Et Dybere Dyk: Netværks-ACL'er og Rute-Tabeller

Hvis sikkerhedsgruppen er korrekt konfigureret, men du stadig oplever en timeout, skal vi kigge på de næste lag i AWS' netværksinfrastruktur: Network Access Control Lists (NACLs) og Route Tables.

Netværks-ACL'er (Network ACLs)

Netværks-ACL'er fungerer som en firewall på subnet-niveau, et lag yderligere ude end sikkerhedsgrupper. Den vigtigste forskel er, at NACL'er er 'stateless'. Det betyder, at du skal definere regler for både indgående OG udgående trafik. En sikkerhedsgruppe er 'stateful', så hvis indgående trafik er tilladt, bliver returtrafikken automatisk tilladt.

For en standard-VPC er standard-NACL konfigureret til at tillade al trafik i begge retninger. Men hvis du eller din organisation har oprettet brugerdefinerede NACL'er, skal du verificere følgende:

• Indgående Regel: Der skal være en regel, der TILLADER trafik på TCP-port 22 fra din IP-adresse (eller 0.0.0.0/0).
• Udgående Regel: Der skal være en regel, der TILLADER trafik til din IP-adresse på de såkaldte 'ephemeral ports' (typisk porte 1024-65535). Da du ikke kender den præcise port, er det nemmest at have en regel, der tillader al udgående TCP-trafik til din IP eller 0.0.0.0/0.

Sammenligning: Sikkerhedsgrupper vs. Netværks-ACL'er

Rute-Tabeller (Route Tables)

For at din instans kan kommunikere med internettet, skal dens subnet have en rute til en Internet Gateway (IGW). Gå til VPC-konsollen, find 'Route Tables', og vælg den tabel, der er associeret med din instans' subnet. Der skal være en rute, der ser nogenlunde sådan ud:

• Destination: 0.0.0.0/0
• Target: igw-xxxxxxxx (navnet på din Internet Gateway)

Hvis denne rute mangler, er din instans i et privat subnet og kan ikke nås direkte fra internettet. Dette er en designbeslutning og kan kræve opsætning af en bastion host eller VPN for at få adgang.

Systematisk Fejlfinding: En Tjekliste

Brug denne tjekliste til at gennemgå alle potentielle problemområder i en logisk rækkefølge.

1. Verificer Instans Status: Er den 'running' i AWS-konsollen?
2. Verificer IP og Nøgle: Bruger du den korrekte offentlige IP og den korrekte .pem-nøgle med de rette filtilladelser (chmod 400)?
3. Test Portforbindelse: Brug et værktøj som telnet eller nc fra din lokale computer. Kør: telnet DIN_EC2_IP 22. Hvis skærmen bliver sort eller viser en SSH-banner, er porten åben. Hvis den hænger og til sidst siger 'connect to address ...: Operation timed out', er porten blokeret. Dette bekræfter, at problemet er i netværket.
4. Analyser Sikkerhedsgruppen: Dette er det mest sandsynlige problem. Gennemgå de indgående regler for port 22. Sørg for, at din IP-adresse er tilladt.
5. Undersøg Netværks-ACL: Tjek både indgående og udgående regler for subnet'et, hvor din instans er placeret.
6. Kontroller Rute-Tabel: Sørg for, at subnet'ets rute-tabel har en rute til en Internet Gateway (0.0.0.0/0 -> igw-...).
7. Tjek for Problemer på Instansen: Hvis alt ovenstående ser korrekt ud, kan problemet ligge på selve operativsystemet. SSH-serveren (sshd) er måske stoppet, eller en lokal firewall (som ufw eller iptables) blokerer port 22. Du kan forsøge at få adgang via 'EC2 Instance Connect' eller 'Systems Manager Session Manager' fra AWS-konsollen for at diagnosticere dette. I yderste nødstilfælde kan man afmontere instansens EBS-volume, tilknytte det til en anden, fungerende instans og undersøge logfiler som /var/log/auth.log.

Ofte Stillede Spørgsmål (FAQ)

Hvorfor virkede min SSH-forbindelse i går, men ikke i dag?

Den mest almindelige årsag er, at din offentlige IP-adresse har ændret sig. De fleste internetudbydere tildeler dynamiske IP-adresser. Hvis din sikkerhedsgruppe er sat til 'My IP', skal du opdatere reglen med din nye IP-adresse.

Er det sikkert at åbne port 22 for 0.0.0.0/0?

Nej, det er en dårlig sikkerhedspraksis. Det giver alle på internettet mulighed for at forsøge at logge ind på din server. Dette udsætter dig for brute-force angreb. Begræns altid kilden til din specifikke IP-adresse, når det er muligt.

Min webserver på port 80 virker, men SSH på port 22 gør ikke. Hvorfor?

Dette er et klassisk tegn på et problem, der er specifikt for port 22. Det bekræfter, at den generelle netværksforbindelse (rute-tabel, NACL) sandsynligvis er i orden. Fokuser din fejlfinding 100% på sikkerhedsgruppens regel for port 22 og på at sikre, at SSH-tjenesten (sshd) kører på selve instansen.

Hvad gør jeg, hvis jeg har mistet min .pem-nøgle?

Du kan ikke downloade den private nøgle igen. Der er dog metoder til at genvinde adgang. En almindelig metode er at tage et snapshot af rod-volumen, oprette en ny instans fra dette snapshot og vælge et nyt nøglepar under oprettelsen.