Mely VPN-portokat kell megnyitni egy tűzfalon: protokollról protokollra

Két külön szabály dönti el, átjut-e egy VPN-alagút a tűzfalon: a port, amelyre a kliens tárcsáz, és a protokoll, amely a hasznos terhet szállítja. Csak az elsőt nyisd meg, és az alagút hitelesít, de utána nem mozdul adat. A minimum egy TCP-port és GRE a PPTP-hez, két UDP-port és ESP az L2TP/IPsec és az IKEv2 számára, és egyetlen port az SSTP, OpenVPN és WireGuard számára. Az irány, az állapotkövetés és a NAT dönti el a többit.

Kezdd azzal a porttal, amelyre a kliens tárcsáz

Minden családnak van egy belépési pontja, amelyet a kliens először felkeres, és az engedélyező szabálynak éppen ezt a belépési pontot kell megneveznie. A PPTP-kliensek a TCP 1723-hoz csatlakoznak. Az L2TP/IPsec UDP 500-on indítja az IKE-t, és átvált UDP 4500-ra, amikor NAT-átjárást használnak, maga az L2TP-keret pedig UDP 1701-en van az alagúton belül. Az SSTP TLS-be csomagolja a munkamenetet TCP 443-on, az IKEv2 UDP 500-on és 4500-on tárgyal, az OpenVPN alapértelmezésben UDP 1194-et használ, de gyakran TCP 443-ra teszik át, a WireGuard pedig UDP 51820-on figyel.

Tekintsd ezeket a számokat alapértékeknek, ne fix tulajdonságoknak. A WireGuard-interfész azt a figyelő portot használja, amelyet a konfigurációja megad, az OpenVPN-szerver pedig bármelyik porton ülhet, amelyet az adminisztrátor választott. Olvasd el a szerver konfigurációját a szabály megírása előtt, mert az 1194-hez nyitott tűzfal semmit sem tesz egy 443-ra áthelyezett szerverért.

A harmadik oszlop az, ahol a legtöbb változási jegy elromlik. A szabály létezik, de rossz célra, rossz irányra vagy rossz átvitelre mutat.

A GRE és az ESP protokollszám, nem port

A GRE-nek és az ESP-nek egyáltalán nincs portja, ezért egy csak portszámokat elfogadó tűzfal-űrlap nem tudja kifejezni őket. A GRE az IP 47-es protokoll, az ESP az IP 50-es protokoll, mindkettőt az IP-fejléc protokollmezője alapján illesztik. A TCP 47-es portként írt szabály semmire sem illeszkedik, és így a PPTP-szabályzat helyesnek látszik, mégis minden csomagot eldob a kézfogás után.

Az otthoni routerek ezt egy átjárást engedélyező jelölőnégyzet mögé rejtik, amely telepíti a protokollszabályt, a GRE esetében pedig a folyamat leképezéséhez szükséges NAT-segédet. Egy igazi tűzfalon magad adod hozzá a protokollt: engedélyezd az IP 47-es protokollt a PPTP-szerver felé, engedélyezd az IP 50-es protokollt az IPsec-átjáró felé. Ahol a platform nem kínál protokollmezőt, ott a beágyazás a kiút, ezért eshet vissza az IKEv2 UDP 4500-ra, és ezért nem találkozik soha az OpenVPN és a WireGuard a problémával.

Ellenőrizd, mihez illeszkedik valójában a szabály, mielőtt a klienst hibáztatod. Az átjárón nullán maradó csomagszámláló azt mondja, hogy a szabály soha nem lépett életbe, és ezen a kliensoldali újratelepítés semmit sem változtat.

Az irány, az állapot és a NAT megváltoztatja a választ

Egy kifelé tárcsázó kliens és egy befelé figyelő átjáró különböző követelmény, és ugyanaz a portlista lehet helyes az egyik irányban és hibás a másikban. Az állapotkövető tűzfal követi az UDP-folyamatot az 500-on és 4500-on, és második szabály nélkül engedi vissza a válaszokat. Az ESP és a GRE nem hordoz portot, ezért a NAT-eszköznek nincs mihez kapaszkodnia, és segédre vagy beágyazásra van szüksége a munkamenet követéséhez.

A NAT-átjárás az a rész, amely kimarad. Az IKEv2 UDP 500-on indul, felismeri a NAT-eszközt, és UDP 4500-on folytatja, ezért a csak 500-at engedélyező szabályzat olyan alagutat ad, amely felépül, majd elhallgat. Az L2TP/IPsec ugyanezt a lépést teszi. Ha a rögzítésed az első cserét mutatja, de tartós forgalmat nem, keress egy szabályt, amely 500-nál megáll.

Jegyezd fel az irányt minden szabállyal. Az „UDP 4500 engedélyezése” semmit sem jelent, amíg nem mondod meg, honnan hová, és a barangoló klienshez helyes szabály általában hibás egy telephely-telephely partnerhez.

Ellenőrizd az egyes útvonalakat rögzítéssel

Az átjárón futtasd a rögzítést, ne a kliensen: a kliens csak azt rögzíti, ami megérkezett. Ezek a szűrők lefedik a fenti családokat, és megmutatják, melyik szakasz hiányzik:

sudo tcpdump -ni any tcp port 1723
sudo tcpdump -ni any udp port 500 or udp port 4500
sudo tcpdump -ni any proto gre
sudo tcpdump -ni any proto 50

Olvasd a kimenetet sorozatként. Amikor a tárgyalás megjelenik, de a hasznos teher protokollja nem, az eldobás valahol a kliens és az átjáró között történik. Amikor mindkettő megjelenik, és az oldal mégis meghiúsul, a tűzfal már nem gyanús; nézd az útválasztást, a DNS-t vagy a kliensnek adott címtartományt.

tcpdump nélküli gépen ugyanezeket a bizonyítékokat az interfész- és szabályszámlálók adják. Az alagút interfészén bejövő, de ki nem menő bájtok a visszaútra mutatnak, nem a kezdeti engedélyező szabályra.

Hagyj magad mögött védhető szabályrendszert

A TCP 443-on futó SSTP semmilyen portalapú szűrő számára nem különböztethető meg a közönséges HTTPS-től, és éppen ez a lényeg, amikor a hálózat csak webtrafikát engedélyez. Ezért is kell a 443-as szabálynak az átjárót megneveznie célként a teljes internet helyett. Töröld az ideiglenes bármi-bárhová szabályokat, amint az alagút működik. Írd fel, melyik szabály illeszkedett, a protokollszámot, ahol van, és az irányt, hogy a következő ember bizonyítékból induljon ki.

A felhő pont-telephely átjárók láthatóvá teszik a választást: a letöltött profil vagy SSTP-t használ a 443-on, vagy IKEv2-t az 500-on és 4500-on, és csak azt szabad megnyitni, amelyiket a profil valóban választ. A PPTP nem ér meg egy GRE-kivételt modern hálózaton, mert a mobilszolgáltatók gyakran eldobják a 47-es protokollt, függetlenül a tűzfaladtól. Mielőtt lezárod a jegyet, erősítsd meg, hogy a szabály a szerver konfigurációjában szereplő portra illeszkedik, hogy a protokollmező ott van beállítva, ahol a családnak szüksége van rá, és hogy a cél az átjáró, nem pedig bármilyen cím.