VPN ruuteril või pordi edasisaatmine: kumb võidab?

Pordi edasisaatmine võib ruuteri VPN-kuulaja porti varastada. Kontrollige sihtkoha omanikku, eemaldage ainult vastuoluline vastendus ja testige iga perekonda.

Ruuter lõpetab VPN-i ise, ja vana edasisaatmise reegel saadab endiselt sama UDP-pordi LAN-is asuvale masinale. Ainult üks neist saab olla tegelik lõpp-punkt, ja tuum nende vahel ei otsusta. Sihtkoha tõlkimine kirjutab paketi ümber enne, kui kohalikku teenust küsitakse, seega VPN-protsess ootab liiklust, mis on juba mujale saadetud. Ülesanne on otsustada, kellele port kuulub, ja seejärel reeglid omavahel kooskõlla viia.

Üks port, kaks väidetavat omanikku

Ruuteri sees töötav VPN-server vajab sissetulevat luba, mis viib tema enda soketini. Sama pordi sihtkoha-NAT-kirje viib hoopis mujale: LAN-i aadressile ja edasisaatmise otsusele. Need on erinevad lõpp-punktid erinevate logide ja erinevate rikkerežiimidega. Tavaline vihje on see, et üks aadressiperekond töötab ja teine mitte, sest ülejäänud kirje kirjutati ühe perekonna jaoks ega vaadatud kunagi uuesti üle.

Kirjutage nõue enne muutmist üles: perekond, väline aadress, transport, port ja tõlgitud sihtkoht.

Tõlkimine käib enne kohalikku kontrolli

Sihtkoha-NAT muudab paketi sihti eelruutimise etapis, enne kui tuum valib kohaliku kohaletoimetamise ja edasisaatmise vahel. Kui sihtkohaks saab LAN-i host, läheb pakett edasisaatmise teele. Ruuteri enda soketi sisendreegleid ei vaadata kunagi, mistõttu jääb VPN-i logi tühjaks, kuni kliendil aegub.

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

See järjekord on kogu mehhanism, ja seadmete liidesed peidavad selle märkeruutude taha seda muutmata. Paketi tee üle otsustab endiselt sihtkoha omanik.

Kui LAN-i host on kavandatud lõpp-punkt, on edasisaatmine õige ja ruuter ei peaks samal pordil ka kuulama.

Jätke üks vastendus ja eemaldage teine

Loetlege selle pordi ja perekonna NAT-kirjed ning valige ellujääja:

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

Sama numbriga TCP-kirje on UDP-tõrke jaoks tähtsusetu, ja nende käsitlemine ühe objektina viib vale reegli kustutamiseni. Kui kohalik soket peaks võitma, eemaldab või kirjutab vastuolulise vastenduse omanik selle ühe kirje ümber, ja ruuteri enda pordi sissetulev luba jääb paigale. Mitteseotud edasisaatmised, haldustee ja reeglistiku koopia peaksid kõik muudatuse üle elama.

Kui VPN elab eraldi hostil, on edasisaatmine õige objekt. Konteineris või virtuaalmasinas olev teenus võib vajada avaldatud porti ka siis, kui kasti nimetatakse ruuteriks, seega jälgige soketit ja selle nimeruumi, mitte korpuse silti.

Kinnitage omanik väljastpoolt

Testige iga perekonda eraldi, sest ruuteril lõppev IPv6-ühendus ei ütle midagi IPv4-ühenduse kohta, mille vana reegel ümber suunab. Lugege vastuvõtva teenuse logi, et näha, milline lõpp-punkt vastas, ja pidage kliendi õnnestumisteate tõendit nõrgaks. Sisuka testi jaoks on vaja uut voogu. Saatke sond välisest hostist käsuga nc -zvu 203.0.113.7 1194 ja lugege võitja logi käsuga journalctl -u openvpn@server -n 20. Ruuteri kuulaja logib ühenduse ise, samas kui LAN-i host logib selle oma teenuses.

Ühenduste jälgimine hoiab olemasolevad vood nende algsel vastendusel, seega võib loodud sessioon üle elada reegli, mille te just parandasite.

Kui kavandatud lõpp-punkt vastab oma tavapäraste identiteedikontrollidega, testige tunnelitagust privaatset ressurssi. Välise kuulajani jõudmine on alles esimene hüpe; sisemine marsruutimine ja rakenduse autoriseerimine on eraldi tulemused.

Seotud artiklid