Kiujn VPN-pordojn malfermi en fajroŝirmilo: protokolo post protokolo

Du apartaj reguloj decidas, ĉu VPN-tunelo travivos fajroŝirmilon: la pordo, kiun la kliento vokas, kaj la protokolo, kiu portas la ŝarĝon. Malfermu nur la unuan, kaj la tunelo aŭtentiĝos, sed poste neniu datumo moviĝos. La minimumo estas unu TCP-pordo kaj GRE por PPTP, du UDP-pordoj kaj ESP por L2TP/IPsec kaj IKEv2, kaj unu pordo por SSTP, OpenVPN kaj WireGuard. Direkto, stato-spurado kaj NAT decidas la reston.

Komencu per la pordo, kiun la kliento vokas

Ĉiu familio havas enirpunkton, kiun la kliento kontaktas unue, kaj ĝuste tiun enirpunkton via permesa regulo devas nomi. PPTP-klientoj konektiĝas al TCP 1723. L2TP/IPsec komencas IKE sur UDP 500 kaj transiras al UDP 4500, kiam NAT-trapaso estas uzata, dum la L2TP-kadro mem estas sur UDP 1701 ene de la tunelo. SSTP envolvas la sesion en TLS sur TCP 443, IKEv2 interkonsentas sur UDP 500 kaj 4500, OpenVPN defaŭlte uzas UDP 1194 sed ofte estas movata al TCP 443, kaj WireGuard aŭskultas sur UDP 51820.

Traktu tiujn nombrojn kiel defaŭltojn, ne kiel fiksajn ecojn. WireGuard-interfaco uzas ajnan aŭskultan pordon, kiun ĝia agordo deklaras, kaj OpenVPN-servilo povas sidi sur ajna pordo, kiun la administranto elektis. Legu la servilan agordon antaŭ ol skribi la regulon, ĉar fajroŝirmilo malfermita por 1194 faras nenion por servilo movita al 443.

La tria kolumno estas kie plej multaj ŝanĝbiletoj misfunkcias. La regulo ekzistas, sed ĝi montras al la malĝusta celo, la malĝusta direkto aŭ la malĝusta transporto.

GRE kaj ESP estas protokolaj numeroj, ne pordoj

GRE kaj ESP tute ne havas pordojn, do fajroŝirmila formularo, kiu akceptas nur pordajn numerojn, ne povas esprimi ilin. GRE estas IP-protokolo 47 kaj ESP estas IP-protokolo 50, ambaŭ akordigitaj per la protokola kampo de la IP-kapo. Regulo skribita kiel TCP-pordo 47 akordiĝas kun nenio, kaj tiel PPTP-politiko aspektas ĝusta kaj tamen forĵetas ĉiun paketon post la manpremo.

Hejmaj enkursigiloj kaŝas tion malantaŭ trapasa markobutono, kiu instalas la protokolan regulon kaj, por GRE, la NAT-helpanton bezonatan por mapi la fluon. Sur reala fajroŝirmilo vi aldonas la protokolon mem: permesu IP-protokolon 47 al la PPTP-servilo, permesu IP-protokolon 50 al la IPsec-pordego. Kie la platformo ne proponas protokolan kampon, enkapsuligo estas la elirejo, tial IKEv2 povas retroiri al UDP 4500 kaj tial OpenVPN kaj WireGuard neniam renkontas la problemon.

Kontrolu, kun kio la regulo efektive akordiĝas, antaŭ ol kulpigi la klienton. Paketnombrilo, kiu restas nule sur la pordego, diras ke la regulo neniam ekfunkciis, kaj neniu kvanto de reinstalado ĉe la klienta flanko tion ŝanĝas.

Direkto, stato kaj NAT ŝanĝas la respondon

Kliento, kiu vokas eksteren, kaj pordego, kiu aŭskultas internen, estas malsamaj postuloj, kaj la sama pordolisto povas esti ĝusta en unu direkto kaj malĝusta en la alia. Stato-konscia fajroŝirmilo spuras la UDP-fluon sur 500 kaj 4500 kaj lasas respondojn reveni sen dua regulo. ESP kaj GRE portas neniujn pordojn, do NAT-aparato havas nenion por kroĉiĝi kaj bezonas helpanton aŭ enkapsuligon por sekvi la sesion.

NAT-trapaso estas la parto, kiu ofte mankas. IKEv2 komenciĝas sur UDP 500, detektas NAT-aparaton kaj daŭrigas sur UDP 4500, do politiko, kiu permesas nur 500, donas tunelon, kiu establiĝas kaj poste silentas. L2TP/IPsec faras la saman movon. Se via kapto montras la unuan interŝanĝon sed ne daŭran trafikon, serĉu regulon, kiu haltas ĉe 500.

Notu la direkton kun ĉiu regulo. «Permesu UDP 4500» signifas nenion ĝis vi diras de kie al kie, kaj regulo ĝusta por migranta kliento kutime malĝustas por partnero de loko-al-loko.

Kontrolu ĉiun vojon per kapto

Rulu la kapton sur la pordego, ne sur la kliento: kliento registras nur tion, kio alvenis. Ĉi tiuj filtriloj kovras la suprajn familiojn kaj montras, kiu etapo mankas:

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

Legu la eligon kiel sinsekvon. Kiam intertraktado aperas sed la ŝarĝa protokolo ne, la forĵeto okazas ie inter kliento kaj pordego. Kiam ambaŭ aperas kaj la paĝo ankoraŭ malsukcesas, la fajroŝirmilo jam ne estas la suspektato; rigardu enkursigon, DNS aŭ la adresaron donitan al la kliento.

Sur maŝino sen tcpdump, la samajn pruvojn donas interfacaj kaj regulaj nombriloj. Bajtoj eniras sed ne eliras sur la tunela interfaco — tio montras al la revena vojo, ne al la komenca permesa regulo.

Lasu regul-aron, kiun vi povas defendi

SSTP sur TCP 443 ne distingeblas de ordinara HTTPS por iu ajn pordbazita filtrilo, kaj tion celas kiam reto permesas nur retan trafikon. Tial ankaŭ la regulo por 443 devas nomi la pordegon kiel celon anstataŭ la tutan interreton. Forigu portempajn regulojn de io-al-io tuj kiam la tunelo funkcias. Notu, kiu regulo akordiĝis, la protokolan numeron kie ekzistas, kaj la direkton, por ke la sekva persono komencu de pruvoj.

Nubaj pordegoj de punkto-al-loko igas la elekton videbla: la elŝutita profilo uzas aŭ SSTP sur 443 aŭ IKEv2 sur 500 kaj 4500, kaj vi devas malfermi nur tiun, kiun la profilo efektive elektas. PPTP ne indas la GRE-escepton sur moderna reto, ĉar poŝtelefonaj operatoroj ofte forĵetas protokolon 47 sendepende de via fajroŝirmilo. Antaŭ ol fermi la bileton, konfirmu ke la regulo kongruas kun la pordo en la servila agordo, ke la protokola kampo estas agordita tie, kie la familio bezonas ĝin, kaj ke la celo estas la pordego, ne ia ajna adreso.