Արդյո՞ք առևտրային VPN-ը արգելափակում է 5432 պորտը. համեմատեք ձեր տարբերակները

Ծրագիրը ամեն օր գրասենյակից խոսում էր իր տվյալների բազայի հետ: Հետո ինչ-որ մեկը միացրեց առևտրային VPN-ի հաճախորդը նույն նոթբուքի վրա, և կապը սկսեց վերակայվել ձեռքսեղմումից հետո: Ծրագրում ոչինչ չփոխվեց, թունելը հայտնում է, որ առողջ է, և այն ֆայրվոլը, որը դուք վերահսկում եք, արգելափակող կանոն չունի: Փոխվեց ելքի ուղին. մատակարարի սերվերները համօգտագործվող, մեծ երթևեկությամբ ծայրակետեր են, և մատակարարները զտում են ելքային պորտերը՝ չարաշահումները նվազեցնելու համար: Տվյալների բազայի և փոստի ուղարկման պորտերը ստանում են դրա մեծ մասը, որովհետև հենց այդ պորտերն են գրավում սկանավորում և սպամ անանուն հասցեների լողավազանից:

Հինգ րոպեի թեստը, որն առանձնացնում է զտումը մնացած ամեն ինչից

Նույն մեքենայից ստուգեք մի պորտ, որը պետք է բաց լինի, և այն պորտը, որը ձախողվում է, նույն հոսթի վրա՝ թունելը միացված և հետո անջատված: Երկու անգամ էլ օգտագործեք նույն հրամանը, որպեսզի միակ փոփոխականը թունելը լինի:

Test-NetConnection db.example.com -Port 443
Test-NetConnection db.example.com -Port 5432
nc -vz -w3 db.example.com 5432

Չորս արդյունք ծածկում են գրեթե բոլոր դեպքերը: Եթե 443-ը աշխատում է, իսկ 5432-ը ձախողվում է միայն թունելի միացված ժամանակ, դուք տեսնում եք պորտերի զտում ելքի ուղու վրա: Եթե երկուսն էլ ձախողվում են թունելով և երկուսն էլ աշխատում են առանց դրա, խնդիրը երթուղավորումն է կամ DNS-ը, ոչ թե պորտի քաղաքականությունը: Եթե երկու պորտն էլ միանում են, բայց ծրագիրը դեռ ձախողվում է, սխալը նույնականացման կամ TLS-ի մեջ է, ոչ թե հասանելիության: Եվ եթե ձախողվում է մատակարարի միայն մեկ սերվերի տեղակայում, դա սերվերային քաղաքականություն է, ուստի ցանկացած կարգավորում ձեռք տալուց առաջ փորձեք այլ տեղակայում:

Առաջին տարբերակ՝ բաժանված թունել տվյալների բազայի ենթացանցի համար

Եթե նոթբուքին առևտրային VPN-ը պետք է միայն այլ նպատակների համար, բացառեք տվյալների բազայի հասցեների միջակայքը թունելից, որպեսզի երթևեկությունը երբեք չմտնի համօգտագործվող ելք: Սա ամենամաքուր տարբերակն է, երբ երկու ուղիներն իսկապես պետք չէ, որ հանդիպեն, և այն ոչինչ չարժե, բացի այն երթուղային կանոնից, որը կարող եք փաստաթղթավորել: Փոխզիջումն այն է, որ բաժանված թունելը ներմուծում է երկրորդ քաղաքականության մակերես՝ այն, ինչ բացառվում է թունելից, պետք է լինի դիտավորյալ, ոչ թե ավելի ուշ ինչ-որ մեկի ավելացրած ենթացանցի կողմնակի ազդեցություն:

Այն դադարում է աշխատել այն պահին, երբ տվյալների բազան գտնվում է այն ցանցի ներսում, որին VPN-ը պետք է հասնի, ուստի ստուգեք դա նախքան դրանով պարտավորվելը:

Երկրորդ տարբերակ՝ ձեր սեփական ծայրակետը, ձեր սեփական ելքը

VPS-ի վրա փոքր VPN ծայրակետ վարելը ելքի քաղաքականության վերահսկողությունը տալիս է ձեզ, և ոչ մի համօգտագործվող լողավազան ներգրավված չէ: Սա այն տարբերակն է, որն արժե ազնվորեն համեմատել առևտրային հաճախորդի հետ. դուք շահում եք կանխատեսելի աղբյուրի հասցե և կորցնում մատակարարի համաշխարհային հետքն ու հարմարավետությունը: Թիմի համար, որն ամբողջ օրը պետք ունի տվյալների բազայի և փոստի պորտեր, փոխզիջումը սովորաբար թեքվում է հօգուտ ծայրակետին տիրելու, որովհետև ձախողման ձևը դառնում է ձեր սեփական սխալ կարգավորումը, այլ ոչ թե ինչ-որ մեկի չարաշահման քաղաքականությունը:

Համեմատեք երկուսին աղբյուրի հասցեի կայունությամբ, նրանով, թե ով կարող է կարդալ ձեր երթևեկությունը, և նրանով, թե ինչ է տեղի ունենում այն օրը, երբ ծայրակետի մատակարարը փոխում է իր զտումը:

Երրորդ տարբերակ՝ հանեք նոթբուքը ուղուց

CI աշխատանքը, պլանավորված կոնտեյները կամ թույլատրված ցանցի ներսում գտնվող ամրոց-հոսթը կախված չեն մարդու թունելի վիճակից: Հասեք տվյալների բազային SSH թունելով արդեն թույլատրված հոսթից, և նոթբուքը երբեք ուղղակիորեն չի խոսում պորտի հետ: Սա այն տարբերակն է, որը մասշտաբավորվում է, երբ մի քանի մարդ հանդիպում է նույն սահմանափակմանը, և հենց այն է, որը վերացնում է խնդիրը՝ շրջանցելու փոխարեն:

Այն ավելի շատ նախնական աշխատանք է պահանջում, քան բաժանված թունելի կանոնը, և չի օգնում այն մեկ մարդուն, որին հենց հիմա ինտերակտիվ նստաշրջան է պետք:

Ինչու մատակարարի հասցեն թույլատրվածների ցանկում դնելը սխալ համեմատություն է

Մատակարարի ելքի հասցեն տվյալների բազայի թույլատրվածների ցանկում ավելացնելը աշխատում է, և այն նաև հասանելիություն է տալիս յուրաքանչյուր այլ բաժանորդի, որը տվյալ պահին կիսում է այդ հասցեն: Նեղ տրված հավելվածային հաշվի հետևում գտնվող միայն-ընթերցման պատճենի համար բացահայտումը կարող է մեկ օր տանելի լինել: Գրելի ամեն ինչի համար սա անուն տալու արժանի փոխզիջում չէ, և պտտվող ելքի հասցեները վատացնում են. յուրաքանչյուր սերվերի փոփոխություն կոտրում է կանոնը, և սպասարկումը հրավիրում է լայն CIDR գրառումներ, որոնք զրոյացնում են թույլատրվածների ցանկի նպատակը:

Նվիրված կամ ստատիկ հասցեները, որտեղ մատակարարը վաճառում է դրանք, սրա միակ տարբերակն են, որը մասշտաբավորվում է: Կապեք թույլատրվածների ցանկը հասցեի, որը միայն ձերն է, կամ ընդհանրապես չկապեք:

Ինչ էլ ընտրեք, գրեք ուղին և պատճառը: Հաջորդ մարդը կհանդիպի նույն վերակայվող կապին և կսկսի մեղադրել ծրագրին: