IP static IPv4 si IPv6 cu Netplan pe Ubuntu, pas cu pas

Sa schimbi setarile de retea ale unui server la care ajungi doar prin retea e varianta de sysadmin a taiatului crengii pe care stai. O indentare gresita intr-un fisier YAML sau un gateway scris gresit, si sesiunea SSH ingheata in mijlocul comenzii, lasandu-te cu un VPS perfect sanatos cu care nu mai poate vorbi nimeni. Vestea buna e ca Ubuntu vine cu o unealta facuta exact pentru momentul asta. In tutorialul de azi scriem o configuratie Netplan curata, cu adrese IPv4 si IPv6 statice, gateway-uri, servere DNS si IP-uri suplimentare, si o aplicam cu netplan try, care pune automat inapoi configuratia veche daca pierdem legatura.

Netplan e dezvoltat de Canonical si documentat pe netplan.io . Este modul standard de configurare a retelei pe Ubuntu inca din versiunea 17.10, deci pe un VPS proaspat cu Ubuntu 24.04 e deja instalat si deja la comanda. Il folosim cu placere pe masinile noastre cu Ubuntu, pentru ca un singur fisier YAML, usor de citit, se verifica mult mai simplu decat o gramada de fisiere de interfata imprastiate, si pentru ca netplan try ne-a salvat mai mult de o fereastra de mentenanta tarzie.

Ce este Netplan si de ce il foloseste VPS-ul tau

Netplan nu e un daemon de retea. E un traducator. Descrii reteaua pe care o vrei intr-un fisier YAML din /etc/netplan/, iar Netplan transforma descrierea in formatul de configurare al unui “renderer”, adica programul care configureaza efectiv placa de retea. Pe Ubuntu Server renderer-ul e systemd-networkd; pe Ubuntu Desktop e de obicei NetworkManager. Dupa ce traducerea e gata, Netplan se da la o parte si renderer-ul face treaba.

Designul asta are un avantaj mare: inveti o singura sintaxa. Fie ca e vorba de un laptop sau de un VPS, adresele, rutele si serverele DNS se scriu la fel, iar acelasi fisier poate fi citit si verificat de oricine din echipa.

Recapitulare rapida de retelistica

Daca stii deja ce inseamna un /64, sari mai departe. Daca nu, iata conceptele pe care le folosim in articol:

• Adresa IP: numarul care identifica serverul tau intr-o retea, ca o adresa postala. Adresele IPv4 arata ca 203.0.113.10; cele IPv6 arata ca 2001:db8:1234::10. :: e o prescurtare pentru “un sir de zerouri”.
• Prefix (sau netmask): /24 sau /64 scris dupa adresa. Spune cati biti de la inceput descriu reteaua, deci care alte adrese sunt “vecini” pe care serverul ii poate atinge direct. /24 la IPv4 inseamna 256 de adrese care au primele trei numere in comun; /64 e dimensiunea standard a unei retele IPv6.
• Gateway: routerul catre care serverul trimite traficul cand destinatia nu e un vecin, adica aproape tot internetul. In Netplan se exprima ca ruta default.
• Servere DNS (resolvere): serverele care traduc nume precum dreamserver.ro in adrese IP. Fara ele, ping-ul pe IP merge, dar nimic din ce foloseste nume nu merge.
• DHCP si router advertisements: metode automate prin care serverul isi primeste adresa. DHCP e uzual pentru IPv4; IPv6 poate folosi si SLAAC, unde routerul anunta reteaua si serverul isi construieste singur adresa. “Static” inseamna doar ca scriem noi valorile, in loc sa le cerem retelei.

De ce IP static pe un VPS?

Multe imagini de VPS pornesc cu DHCP pentru IPv4 si asta merge foarte bine in prima zi. Configuratia statica incepe sa aiba sens cand:

• ai comandat adrese IPv4 suplimentare sau vrei sa folosesti mai multe adrese din subnetul IPv6, pe care DHCP nu ti le da singur;
• subnetul IPv6 e alocat static de furnizor si nu e anuntat prin DHCPv6 sau SLAAC, deci serverul nu are IPv6 pana nu il configurezi tu;
• vrei ca reteaua sa porneasca identic la fiecare boot, fara sa depinzi de un server DHCP care sa raspunda la timp;
• rulezi servicii (mail, DNS, VPN) unde adresa nu are voie sa se schimbe si trebuie sa se potriveasca cu regulile de firewall si cu reverse DNS.

De ce ai nevoie

• Un VPS cu Ubuntu 24.04 (merge si 22.04, sintaxa e aceeasi). Ideal e un VPS KVM; cine are LXC sa citeasca intai nota de mai jos.
• Un utilizator cu drepturi sudo si o conexiune SSH functionala.
• Datele de retea de la furnizor: adresa IPv4 si prefixul, gateway-ul IPv4, adresa sau subnetul IPv6 cu prefix, gateway-ul IPv6 si serverele DNS pe care vrei sa le folosesti. La un VPS DreamServer le gasesti in zona de client si in emailul de bun venit.
• Acces la consola web (VNC / noVNC) a VPS-ului, daca panoul tau o ofera. E planul B; deschide-o o data inainte sa incepi, doar ca sa stii unde e.
• tmux, instalat implicit pe Ubuntu Server (sudo apt install tmux daca lipseste).
• Cam 15 minute si nicio alta modificare urgenta in desfasurare pe server in acelasi timp.

Toate exemplele folosesc adrese rezervate pentru documentatie (203.0.113.0/24 pentru IPv4 si 2001:db8::/32 pentru IPv6) si numele de interfata eth0. Inlocuieste-le peste tot cu valorile tale. Daca le copiezi exact asa, serverul iese din retea, adica exact ce incercam sa evitam.

Pasul 1: Aduna datele de retea

Mai intai sa vedem cum arata serverul acum. Comanda ip afiseaza interfetele, adresele si rutele:

ip -br link
ip -br addr
ip route show
ip -6 route show

-br vine de la “brief”, adica un rand pe interfata. Rezultatul arata cam asa:

lo               UNKNOWN        127.0.0.1/8 ::1/128
eth0             UP             203.0.113.10/24 metric 100 fe80::5054:ff:fe12:3456/64
default via 203.0.113.1 dev eth0 proto dhcp src 203.0.113.10 metric 100

Retine trei lucruri: numele interfetei (aici eth0; pe multe VPS-uri e ens3, ens18 sau enp1s0), adresa IPv4 actuala si cuvintele proto dhcp, care ne spun ca adresa a venit prin DHCP. Daca singura adresa IPv6 pe care o vezi incepe cu fe80::, aceea e o adresa link-local pe care orice interfata IPv6 o are automat; nu inseamna ca IPv6 e configurat.

Acum uita-te la fisierele Netplan existente:

ls -l /etc/netplan/
sudo cat /etc/netplan/*.yaml

Pe o imagine cloud vei gasi de obicei 50-cloud-init.yaml; pe un sistem instalat din ISO poate fi 50-cloud-init.yaml sau 00-installer-config.yaml. Observa daca fisierul contine un bloc match: cu un macaddress si o linie set-name:. Asta inseamna ca interfata e redenumita la boot si trebuie sa pastram blocul, revenim la asta in pasul 4.

La final, noteaza valorile intr-un singur loc. Un tabel mic intr-un fisier text pe calculatorul tau e perfect:

Unii furnizori dau ca gateway IPv6 fe80::1, o adresa link-local. E perfect valid, iar Netplan il accepta exact asa.

Pasul 2: Fa backup la configuratia actuala

Inainte sa atingi ceva, copiaza directorul Netplan actual intr-un loc sigur:

sudo mkdir -p /root/netplan-backup
sudo cp -a /etc/netplan/. /root/netplan-backup/
sudo ls -l /root/netplan-backup/

Optiunea -a pastreaza permisiunile si datele fisierelor, iar /. de la final copiaza continutul directorului, nu directorul in sine. Ultima comanda trebuie sa afiseze aceleasi nume de fisiere pe care le-ai vazut in pasul 1.

De ce /root/netplan-backup si nu /etc/netplan/vechi.yaml? Pentru ca Netplan citeste toate fisierele cu extensia .yaml din /etc/netplan/ si le combina in ordine alfabetica. O copie de rezerva lasata in directorul acela nu e backup, e o a doua configuratie activa care se va bate cu cea noua. Tine backup-urile mereu in afara directorului.

Pasul 3: Opreste cloud-init sa-ti suprascrie modificarile

cloud-init e unealta care configureaza un VPS cloud la primul boot: hostname, chei SSH si, de multe ori, reteaua. Daca fisierul tau Netplan a fost generat de cloud-init, incepe cu un comentariu ca acesta:

# This file is generated from information provided by the datasource.  Changes
# to it will not persist across an instance reboot.  To disable cloud-init's
# network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}

Ia avertismentul ad litteram: pe unele platforme cloud-init rescrie configuratia de retea la boot, iar configuratia statica la care ai muncit dispare dupa urmatorul restart. Ii urmam propriul sfat:

echo 'network: {config: disabled}' | sudo tee /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg

tee scrie linia in fisier cu drepturi de root si o afiseaza inapoi, deci ar trebui sa vezi network: {config: disabled} in terminal. Daca directorul /etc/cloud/ nu exista, sistemul tau nu foloseste cloud-init si poti sari peste pas.

O consecinta de retinut: de acum cloud-init nu mai actualizeaza reteaua in locul tau. Daca mai tarziu schimbi IP-uri din panoul furnizorului, actualizezi tu fisierul Netplan.

Pasul 4: Scrie fisierul YAML Netplan cu IP static si IPv6

Cream un singur fisier nou care descrie complet interfata, apoi il stergem pe cel vechi, ca sa existe o singura sursa de adevar. Deschide editorul:

sudo nano /etc/netplan/10-static.yaml

Lipeste continutul de mai jos, dupa ce ai inlocuit valorile de exemplu cu ale tale:

network:
  version: 2
  renderer: networkd
  ethernets:
    eth0:
      # Daca fisierul vechi avea un bloc match + set-name, copiaza-l aici neschimbat:
      # match:
      #   macaddress: "52:54:00:12:34:56"
      # set-name: eth0
      dhcp4: false
      dhcp6: false
      accept-ra: false
      addresses:
        - 203.0.113.10/24
        - "2001:db8:1234::10/64"
      routes:
        - to: default
          via: 203.0.113.1
        - to: default
          via: "2001:db8:1234::1"
      nameservers:
        addresses:
          - 1.1.1.1
          - 9.9.9.9
          - "2606:4700:4700::1111"
          - "2620:fe::fe"

Salveaza cu Ctrl+O, Enter si iesi cu Ctrl+X. Apoi restrange permisiunile si sterge fisierul vechi (avem copia din pasul 2):

sudo chmod 600 /etc/netplan/10-static.yaml
sudo rm /etc/netplan/50-cloud-init.yaml
ls -l /etc/netplan/

Foloseste numele real al fisierului vechi daca difera. Ultima comanda trebuie sa afiseze doar 10-static.yaml, cu permisiunile -rw-------. Netplan se plange zgomotos cand fisierele lui pot fi citite de alti utilizatori, pentru ca pot contine secrete, de exemplu parole Wi-Fi.

Stergerea fisierului vechi nu schimba inca reteaua care ruleaza; nimic nu se aplica pana la pasul 6.

YAML-ul, linie cu linie

YAML e un format in care indentarea este structura. Foloseste mereu spatii, niciodata tab-uri, si pune fiecare nivel cu doua spatii mai la dreapta decat parintele lui. Iata ce inseamna fiecare parte:

• network: si version: 2: cheia de top si versiunea formatului Netplan. Mereu 2.
• renderer: networkd: predam configuratia catre systemd-networkd, implicit pe Ubuntu Server.
• ethernets: apoi eth0:: setarile pentru interfata Ethernet numita eth0.
• match: si set-name: (comentate): necesare doar daca fisierul vechi le folosea. Identifica placa dupa adresa MAC si ii dau un nume fix. Daca le aveai, scoate comentariul si foloseste exact valorile din fisierul vechi.
• dhcp4: false si dhcp6: false: nu cere adrese automat, le dam noi.
• accept-ra: false: ignora router advertisements IPv6, ca serverul sa nu adauge adrese SLAAC sau rute in plus pe langa cele statice. Daca furnizorul ti-a spus ca IPv6 functioneaza prin router advertisements, pune true sau sterge linia.
• addresses:: lista de adrese cu prefixele lor. IPv4 si IPv6 pot sta in aceeasi lista. Punem valorile IPv6 intre ghilimele ca YAML sa nu interpreteze gresit doua puncte.
• routes: cu to: default: gateway-urile default, unul pentru IPv4 si unul pentru IPv6. Netplan isi da seama singur care e care dupa familia adresei.
• nameservers:: serverele DNS pentru interfata asta, transmise mai departe catre systemd-resolved.

Poate gasesti ghiduri mai vechi care folosesc gateway4: si gateway6:. Cheile astea sunt depreciate si Netplan afiseaza un avertisment cand le vede; forma cu routes: de mai sus e cea actuala.

Cand gateway-ul e in afara subnetului

Unele configuratii iti dau o adresa IPv4 cu prefix /32, adica “doar adresa asta”, si un gateway care nu e in acel interval. In mod normal kernelul refuza o astfel de ruta, pentru ca nu stie cum sa ajunga la gateway. Optiunea on-link: true ii spune: “gateway-ul e direct pe fir, trimite pur si simplu catre el”:

      addresses:
        - 203.0.113.10/32
      routes:
        - to: default
          via: 203.0.113.1
          on-link: true

Foloseste-o doar daca instructiunile furnizorului o cer. Cu un /24 normal si un gateway in interiorul lui, nu ai nevoie de ea.

Pasul 5: Valideaza configuratia cu netplan generate

Inainte sa aplici ceva, cere-i lui Netplan sa citeasca fisierul si sa genereze configuratia pentru backend, fara sa atinga reteaua activa:

sudo netplan generate

Daca nu afiseaza nimic, YAML-ul e valid. Erorile indica fisierul, linia si coloana. Formularea exacta depinde de versiunea Netplan, dar arata cam asa:

/etc/netplan/10-static.yaml:9:1: Invalid YAML: found character that cannot start any token

Mesajul asta inseamna de obicei ca s-a strecurat un tab. Corecteaza linia indicata si ruleaza comanda din nou pana nu mai afiseaza nimic. Poti vedea si configuratia exact asa cum a inteles-o Netplan:

sudo netplan get

Comanda afiseaza rezultatul combinat al tuturor fisierelor. Daca vezi adrese sau interfete la care nu te asteptai, mai exista un fisier .yaml undeva in /etc/netplan/.

Tine minte ca generate prinde greselile de sintaxa, nu pe cele de logica. Un gateway gresit, dar scris corect, trece validarea fara probleme. De asta e atat de important pasul urmator.

Pasul 6: Aplica in siguranta cu netplan try

netplan apply aplica configuratia imediat si definitiv. netplan try o aplica temporar: schimba reteaua, apoi asteapta sa apesi Enter. Daca nu confirmi in timpul alocat (implicit 120 de secunde), revine singur la starea anterioara a retelei. O greseala care iti taie conexiunea te costa deci doua minute, nu un tichet la suport.

Porneste intai o sesiune tmux, ca sa ruleze comanda chiar daca conexiunea SSH se blocheaza sau cade:

tmux new -s net
sudo netplan try

Vei vedea ceva de genul:

Do you want to keep these settings?

Press ENTER before the timeout to accept the new configuration

Changes will revert in 120 seconds

Acum testeaza inainte sa apesi Enter. Deschide un al doilea terminal pe calculatorul tau si conecteaza-te din nou la server:

ssh utilizatorul-tau@203.0.113.10

Daca noua sesiune SSH merge, ruleaza din ea cateva verificari rapide (ping -c 3 1.1.1.1 si ping -6 -c 3 2606:4700:4700::1111), apoi intoarce-te in prima fereastra si apasa Enter. Netplan raspunde cu Configuration accepted. si modificarea devine permanenta.

Daca ai schimbat chiar adresa prin care erai conectat, prima sesiune va ingheta, lucru normal. Conecteaza-te la adresa noua din al doilea terminal, ataseaza-te la sesiunea tmux cu tmux attach -t net si apasa Enter acolo. Acesta e motivul principal pentru care folosim tmux: intrebarea de confirmare te urmeaza pe noua conexiune.

Daca nu merge nimic, nu face nimic. Dupa expirarea timpului Netplan revine, reteaua veche se intoarce, iar sesiunea inghetata de obicei isi revine singura. Poti scurta asteptarea cu sudo netplan try --timeout 60.

Un detaliu important: netplan try readuce reteaua care ruleaza, nu fisierul. Fisierul 10-static.yaml editat e tot pe disc. Corecteaza-l si incearca din nou sau, ca sa revii complet la configuratia initiala:

sudo rm /etc/netplan/10-static.yaml
sudo cp -a /root/netplan-backup/. /etc/netplan/
sudo netplan generate

Nu da niciodata reboot cat timp in /etc/netplan/ sta un fisier gresit, pentru ca urmatorul boot il va aplica fara nicio plasa de siguranta.

Pasul 7: Verifica conectivitatea, DNS-ul si un reboot

Cu configuratia acceptata, verifica fiecare bucata separat. Intai adresele si rutele:

ip -br addr show eth0
ip route show default
ip -6 route show default

Rezultatul asteptat, cu valorile tale:

eth0             UP             203.0.113.10/24 2001:db8:1234::10/64 fe80::5054:ff:fe12:3456/64
default via 203.0.113.1 dev eth0 proto static
default via 2001:db8:1234::1 dev eth0 proto static metric 1024 pref medium

Observa ca proto dhcp a devenit proto static. Apoi testeaza conectivitatea pe ambele protocoale, intai catre gateway, apoi catre internet:

ping -c 3 203.0.113.1
ping -c 3 1.1.1.1
ping -6 -c 3 2606:4700:4700::1111

Fiecare comanda trebuie sa raporteze 3 received si 0% packet loss. Urmeaza DNS-ul. Pe Ubuntu, rezolvarea numelor trece prin systemd-resolved, iar /etc/resolv.conf trimite catre un stub local la 127.0.0.53, deci nu edita fisierul acela de mana. Verifica ce foloseste interfata in realitate:

resolvectl dns eth0
resolvectl query dreamserver.ro

Prima comanda trebuie sa afiseze serverele din YAML; a doua trebuie sa intoarca una sau mai multe adrese. Netplan are si o privire de ansamblu:

sudo netplan status

Afiseaza fiecare interfata cu adresele, rutele si serverele DNS pe un singur ecran, foarte util cand revii la server dupa cateva luni.

La final, testul real: supravietuieste configuratia unui reboot? Tine consola web deschisa in browser, apoi:

sudo reboot

Reconecteaza-te dupa un minut si ruleaza din nou verificarile de mai sus. Daca totul e identic, cloud-init nu mai intervine si configuratia e persistenta. Modificarile Netplan in sine nu au nevoie de reboot; il facem o singura data, ca sa dovedim ca setup-ul rezista.

Adaugarea de adrese IPv4 si IPv6 suplimentare

Adresele in plus sunt pur si simplu intrari noi in lista addresses:. Sa zicem ca ai comandat un al doilea IPv4 in acelasi subnet si vrei un al doilea IPv6 pentru un site separat:

      addresses:
        - 203.0.113.10/24
        - 203.0.113.11/24
        - "2001:db8:1234::10/64"
        - "2001:db8:1234::11/64"

Foloseste acelasi prefix ca la adresa principala cand IP-ul suplimentar e in acelasi subnet. Daca furnizorul iti da un IP dintr-un alt interval, adesea ca /32 la IPv4 sau ca subnet rutat separat, scrie-l cu prefixul indicat de el. In cele mai multe cazuri nu ai nevoie de un al doilea gateway, pentru ca furnizorul ruteaza adresa respectiva catre adresa ta principala. La IPv6 primesti de obicei un /64 intreg, cu mult mai multe adrese decat vei folosi vreodata, deci poti alege oricare adrese libere din el.

Dupa editare, repeta aceeasi rutina sigura: sudo netplan generate, apoi sudo netplan try in tmux, testezi dintr-un al doilea terminal, apesi Enter. Apoi confirma ca noua adresa raspunde, de exemplu cu ping 203.0.113.11 de pe calculatorul tau si, daca ai IPv6 acasa, ping -6 2001:db8:1234::11.

De pe ce adresa pleaca conexiunile?

Traficul care intra poate ajunge la oricare adresa din lista. Conexiunile care pleaca, de exemplu cand serverul trimite email sau apeleaza un API, ies de regula de pe prima adresa din fiecare familie. Poti verifica ce adresa sursa alege kernelul:

ip route get 1.1.1.1
ip -6 route get 2606:4700:4700::1111

Campul src din rezultat e adresa folosita. Daca un anumit serviciu trebuie sa trimita de pe un IP suplimentar, solutia cea mai curata e sa configurezi serviciul sa se lege de acel IP; majoritatea serverelor de mail si web au o optiune pentru asta. Netplan poate seta si o sursa preferata cu from: pe o ruta, dar pentru cei mai multi cititori legarea din aplicatie e mai usor de inteles si de depanat.

Debian 13 si containere LXC: ce e diferit

Netplan e implicit pe Ubuntu. Pe Debian 13, un sistem instalat cu installer-ul standard configureaza reteaua cu ifupdown: fisierul e /etc/network/interfaces, iar serviciul se numeste networking, nu systemd-networkd. Debian are si pachetul Netplan (netplan.io), iar unele imagini cloud Debian il folosesc deja. Testul rapid e acelasi pe ambele: daca ls /etc/netplan arata fisiere YAML, ghidul de fata se aplica. Pe Debian verifica si daca systemd-resolved e instalat; daca nu e, nameservers: din Netplan nu ajung in /etc/resolv.conf, iar DNS-ul il setezi direct in acel fisier.

Daca sistemul tau Debian foloseste ifupdown, configuratia statica echivalenta arata asa:

auto eth0
iface eth0 inet static
    address 203.0.113.10/24
    gateway 203.0.113.1

iface eth0 inet6 static
    address 2001:db8:1234::10/64
    gateway 2001:db8:1234::1

ifupdown nu are un try incorporat, asa ca iti construiesti singur plasa de siguranta intr-o sesiune tmux, inainte sa repornesti serviciul:

sudo -i
cp -a /etc/network/interfaces /root/interfaces.bak
nano /etc/network/interfaces
(sleep 180 && cp -a /root/interfaces.bak /etc/network/interfaces && systemctl restart networking) &
systemctl restart networking

Linia dintre paranteze programeaza o revenire peste 180 de secunde. Daca totul merge in continuare, o anulezi cu kill %1 si apoi exit. Repornirea ifupdown nu sterge mereu curat adresele vechi, asa ca un test de reboot cu consola deschisa ramane o idee buna.

Containerele LXC sunt un caz aparte. Intr-un container LXC, privilegiat sau neprivilegiat, reteaua e configurata de host: IP-ul, gateway-ul si DNS-ul pe care le vezi sunt scrise in container de platforma de virtualizare, iar modificarile facute din interior sunt de obicei suprascrise la urmatoarea pornire. Pe un VPS LXC, schimba IP-urile din panoul furnizorului sau cere ajutorul suportului, in loc sa editezi Netplan in container. Tot tutorialul de fata e gandit pentru VPS KVM, unde kernelul si stiva de retea sunt ale tale.

Depanare: greseli frecvente

• “Invalid YAML” sau “expected mapping (check indentation)”: problema de indentare. Doar spatii, cate doua pe nivel, iar elementele de lista (- ) aliniate sub cheia lor.
• “Permissions for /etc/netplan/10-static.yaml are too open”: ruleaza sudo chmod 600 /etc/netplan/*.yaml. E doar un avertisment, dar rezolva-l.
• "gateway4 has been deprecated, use default routes instead": inlocuieste gateway4 / gateway6 cu blocul routes: din pasul 4.
• “Conflicting default route declarations”: doua fisiere sau doua intrari definesc o ruta default pentru aceeasi familie. De obicei a ramas un .yaml vechi in /etc/netplan/. Ruleaza sudo netplan get ca sa vezi configuratia combinata.
• “Cannot call Open vSwitch: ovsdb-server.service is not running”: inofensiv pe Ubuntu 24.04 cand Open vSwitch nu e instalat. Ignora-l.
• Nu se schimba nimic dupa try sau apply: numele interfetei din YAML nu corespunde cu cel real. Compara cu ip -br link.
• Merge pana la reboot, apoi revine IP-ul vechi: cloud-init si-a regenerat fisierul. Verifica din nou pasul 3 si cauta un 50-cloud-init.yaml proaspat creat.
• Dupa reboot interfata are alt nume si niciun IP: fisierul vechi redenumea interfata cu match + set-name, iar blocul a fost pierdut. Intra prin consola web, adauga blocul la loc si aplica.
• IPv4 merge, IPv6 nu: compara prefixul si gateway-ul cu valorile de la furnizor, apoi ruleaza ip -6 neigh ca sa vezi daca gateway-ul raspunde. Un gateway in afara subnetului are nevoie de on-link: true; un gateway fe80::1 nu are nevoie de nimic special.
• Ping-ul pe IP merge, pe nume nu: problema de DNS. Verifica resolvectl dns eth0; pe Debian fara systemd-resolved, verifica /etc/resolv.conf.
• netplan try se inchide imediat: are nevoie de un terminal interactiv, deci nu il rula dintr-un script sau dintr-un cron.

Note de securitate

• Mai multe adrese, mai multa expunere. Orice serviciu care asculta pe toate adresele (0.0.0.0 sau ::) devine accesibil si pe noile adrese IPv4 si IPv6. Listeaza serviciile cu sudo ss -tulpn si asigura-te ca nu e deschis nimic ce n-ar trebui.
• Firewall si pentru IPv6, nu doar pentru IPv4. Multi securizeaza IPv4 si uita complet de IPv6. Cu ufw, verifica sa fie IPV6=yes in /etc/default/ufw (implicit pe Ubuntu), ca fiecare regula sa se aplice pe ambele. Tine minte si ca porturile publicate de Docker ocolesc ufw; leaga-le de 127.0.0.1 sau de o adresa anume cand nu trebuie sa fie publice.
• Configureaza doar adrese alocate tie. Un IP care apartine altcuiva ii strica serviciul si incalca regulile de utilizare; oricum, filtrele anti-spoofing ale furnizorului vor arunca traficul.
• Seteaza reverse DNS (PTR) pentru IP-urile publice, mai ales pentru servere de mail, din panoul furnizorului sau prin suport.
• Pastreaza consola accesibila. Asigura-te ca stii parola panoului si ca, consola web functioneaza; e singura usa ramasa daca o modificare de retea iese prost.
• Pastreaza permisiunile 600 pentru tot ce e in /etc/netplan/.

Deci, trecem pe IP static?

O configuratie Netplan statica inseamna trei blocuri scurte de YAML: adrese, rute si servere DNS. Adevarata abilitate e sa o aplici fara drame: backup in afara /etc/netplan/, cloud-init oprit, validare cu netplan generate, aplicare cu netplan try in tmux, test dintr-o a doua sesiune si abia apoi Enter. Respecta rutina asta si modificarile de retea nu mai sunt infricosatoare, nici macar pe un server aflat la sute de kilometri.

Daca ai nevoie de un server pe care sa exersezi, poti porni in cateva minute un VPS cu IPv4 si IPv6 in data center-ul nostru din Romania. Iar daca preferi ca altcineva sa se ocupe de planificarea IP-urilor, adrese suplimentare, reverse DNS si firewall, echipa noastra de administrare servere face asta in fiecare zi.

Intrebari frecvente

Trebuie sa dau reboot dupa ce modific Netplan?

Nu. netplan try sau netplan apply activeaza configuratia imediat. Recomandam un singur reboot dupa o modificare mare, doar ca sa confirmi ca setup-ul persista.

Care e diferenta dintre netplan try si netplan apply?

apply face modificarea permanenta pe loc. try o aplica temporar si revine automat daca nu confirmi in timpul alocat, ceea ce il face alegerea sigura pe servere la distanta.

Mai pot folosi gateway4 si gateway6?

Inca functioneaza pe multe versiuni, dar sunt depreciate si afiseaza avertismente. Foloseste in schimb routes: cu to: default.

Ce prefix IPv6 folosesc, /64 sau /128?

Exact ce iti indica furnizorul. Majoritatea VPS-urilor primesc un /64, iar fiecare adresa din el se scrie cu /64.

Merge si pe Debian 13?

Doar daca sistemul foloseste Netplan (verifica cu ls /etc/netplan). O instalare standard de Debian 13 foloseste /etc/network/interfaces; vezi sectiunea despre Debian de mai sus pentru configuratia echivalenta si o plasa de siguranta manuala.