VPN na routeri alebo presmerovanie portu: čo vyhrá?

Presmerovanie portu môže ukradnúť port poslucháčovi VPN na routeri. Skontrolujte vlastníka cieľa, odstráňte len konfliktné mapovanie a otestujte každú rodinu.

Router sám ukončuje VPN a staré pravidlo presmerovania stále posiela ten istý port UDP na stroj v miestnej sieti. Skutočným koncovým bodom môže byť len jedno z nich a jadro medzi nimi nerozhoduje. Preklad cieľa prepíše paket skôr, než sa použije miestna služba, takže proces VPN čaká na prevádzku, ktorá už bola odoslaná inam. Úlohou je rozhodnúť, komu port patrí, a potom zosúladiť pravidlá.

Jeden port, dvaja nárokovaní vlastníci

Server VPN bežiaci vnútri routera potrebuje prichádzajúce povolenie, ktoré vedie k jeho vlastnému socketu. Záznam NAT cieľa pre ten istý port vedie úplne inam: na adresu v miestnej sieti a k rozhodnutiu o presmerovaní. Sú to rôzne koncové body s rôznymi logmi a rôznymi režimami zlyhania. Zvyčajným vodítkom je, že jedna rodina adries funguje a druhá nie, pretože zostávajúci záznam bol napísaný pre jednu rodinu a nikdy sa nepreskúmal.

Pred úpravou si zapíšte nárok: rodina, vonkajšia adresa, transport, port a preložený cieľ.

Preklad beží pred miestnou kontrolou

NAT cieľa mení cieľ paketu vo fáze pred smerovaním, skôr než jadro vyberie medzi miestnym doručením a presmerovaním. Hneď ako sa cieľom stane hostiteľ v miestnej sieti, paket ide cestou presmerovania. Vstupné pravidlá pre vlastný socket routera sa nikdy neskúmajú, preto log VPN zostáva prázdny, kým klient čaká.

Intended local entry:
WAN UDP 1194 -> router local socket -> input path

Conflicting old entry:
WAN UDP 1194 -> DNAT 192.168.50.10:1194 -> forward path

Toto poradie je celý mechanizmus a rozhrania zariadení ho skrývajú za zaškrtávacími políčkami bez toho, aby ho menili. O ceste paketu stále rozhoduje vlastník cieľa.

Ak je hostiteľ v miestnej sieti zamýšľaným koncovým bodom, presmerovanie je správne a router by na tomto porte nemal tiež počúvať.

Ponechajte jedno mapovanie a druhé odstráňte

Vypíšte záznamy NAT pre tento port a rodinu a vyberte toho, kto prežije:

sudo iptables -t nat -S | grep 1194
sudo ss -lunp | grep :1194

Záznam TCP s rovnakým číslom je pre zlyhanie UDP irelevantný a ich spoločné chápanie vedie k vymazaniu nesprávneho pravidla. Keď má zvíťaziť miestny socket, vlastník konfliktného mapovania odstráni alebo prepíše práve ten záznam a prichádzajúce povolenie pre vlastný port routera zostane na mieste. Nesúvisiace presmerovania, cesta správy a kópia sady pravidiel by mali zmenu prežiť.

Ak VPN žije na samostatnom hostiteľovi, presmerovanie je správny objekt. Služba v kontajneri alebo virtuálnom stroji môže potrebovať publikovaný port, aj keď sa skrini hovorí router, preto sledujte socket a jeho menný priestor, nie štítok na skrini.

Potvrďte vlastníka zvonku

Testujte každú rodinu zvlášť, pretože spojenie IPv6, ktoré končí na routeri, nič nehovorí o spojení IPv4, ktoré presmerúva zastarané pravidlo. Prečítajte si log prijímajúcej služby, aby ste videli, ktorý koncový bod odpovedal, a správu klienta o úspechu berte ako slabý dôkaz. Na zmysluplný test je potrebný nový tok. Pošlite sondu z vonkajšieho hostiteľa pomocou nc -zvu 203.0.113.7 1194 a prečítajte log víťaza pomocou journalctl -u openvpn@server -n 20. Poslucháč routera zaznamenáva spojenie sám, zatiaľ čo hostiteľ v miestnej sieti ho zaznamenáva vo svojej službe.

Sledovanie spojení drží existujúce toky na ich pôvodnom mapovaní, takže nadviazaná relácia môže prežiť pravidlo, ktoré ste práve opravili.

Keď zamýšľaný koncový bod odpovie svojimi obvyklými kontrolami identity, otestujte súkromný zdroj za tunelom. Dosiahnuť vonkajšieho poslucháča je len prvý krok; vnútorné smerovanie a autorizácia aplikácie sú samostatné výsledky.

Súvisiace články